[Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

Allan Sandfeld Jensen kde at carewolf.com
Wed Oct 14 12:41:12 CEST 2015


On Tuesday 13 October 2015, Marc Mutz wrote:
> Hi,
> 
> After looking quite a bit into the current state of string handling in Qt
> for my QtWS talk last week, I have become frustrated by the state of
> string handling in Qt.
> 
> We have such powerful tools for string handling (QStringRef,
> QStringBuilder), but all APIs outside QString and its immediate
> surroundings only deal in QString. The correct way would be to overload
> every function taking QString with QLatin1String and QStringRef versions,
> and then, for some other rare cases, const QChar *, int size. Let alone
> std::basic_string<char16_t>.
> 
> I would therefore like to propose to abandon QString for new API (and over
> time phase it out of existing API), and only provide (const QChar*, size_t)
> as the most general form. I would propose to package the two into a class,
> called - you guessed it - QStringView.
> 
Why not a QCharArray? With external data constructor, that should be the same, 
shouldn't it?

Anyway, I doubt this is really something that needs optimizing, QString is 
neat because it is simple and easy to remember.  If anything we need to use 
QByteArray in more places where QStrings are only 8-bit strings.

`Allan



More information about the Development mailing list