Then after we add QStringView, we will have QString for containing a string and
QStringView for passing its contents out of Qt?
martin
________________________________________
From: m...@kdab.com <m...@kdab.com> on behalf of Marc Mutz <marc.m...@kdab.com>
Sent: Friday, October 16, 2015 10:07 AM
To: Smith Martin
Cc: development@qt-project.org
Subject: Re: [Development] RFC: Proposal for a semi-radical change in Qt
APIs taking strings
On Friday 16 October 2015 07:59:40 Smith Martin wrote:
> Can you refocus the discussion for everyone? For me at least?
>
> QString is my favorite class of all time. I use it every day in every
> program; it always works, and I never make a mistake.
Then you can continue to be blissfully ignorant of reality as you are :) If
you are a QString fanboy and don't care about 3rd-party code and/or efficiency,
then you can just continue as before.
> 1. What is the problem with QString that QStringView will solve?
TL;DR: Inefficient conversion from/to QString, leading to inefficiencies within
pure Qt-code and in particular when interfacing with 3rd-party code, BiC
issues,
> 2. Why can't QString be fixed?
Because it is a container, not an interface type.
An interface type needs to be BC across most of compilers and languages (incl.
C and - potentially Java).
A container needs to handle (as in own) memory. An interface type (quite
obviously, if it's to work with C, too) cannot.
> 3. What is a string view?
A pimped { QChar *begin, QChar *end; }
Thanks,
Marc
--
Marc Mutz <marc.m...@kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
