[Development] Qt6: Adding UTF-8 storage support to QString

Arnaud Clère arnaud.clere at minmaxmedical.com
Wed Jan 23 12:47:29 CET 2019

> -----Original Message-----
> From: Thiago Macieira <thiago.macieira at intel.com> 
> On Tuesday, 22 January 2019 09:01:16 PST Arnaud Clère wrote:
> > QByteArray is the official way to deal with utf8 strings but:
> > 1. This discussion shows it is not as known as it should be and I 
> > argue the name does not help 2. Dealing with binary data and all kind 
> > of string encodings in a single class is error-prone
> And yet that's what we used to have in Qt 3 (remember QCString?). We went away from it for a reason.

Sorry no, I never used Qt3. I just googled it looking for problems and only found ones that should be solved now by QByteArray:
- explicit sharing
- bad performance due to append() being O(length()) since it scans for a null terminator

> And 3: some character-mutating operations in QByteArray (toUpper, etc.) are Latin1, not UTF-8.

A QUtf8String could override toUpper() and toLower() which are unfortunate if QByteArray really is the official way to deal with utf-8 strings...

> > Hence my suggestion of adding a QUtf8String deriving from QByteArray...
> Not likely to happen. If we add a QUtf8String, it will be like QLatin1String, which in turn was meant to be similar to QStringView, not like QString. That means no mutation and no owning memory.

The use case I am talking about is really a mutable utf8 container, even though it could provide a QUtf8StringLiteral macro similar to QByteArrayLiteral. I do not understand why a QUtf8String should necessarily be like a QLatinString.

OTOH, I would love to be able to manipulate QLatin1String/QUtf8String with a QStringView when dealing with possibly non-ASCII content. But QStringView seems to require knowing the number of remaining Unicode characters in constant time so I guess it is out of question...

> And I don't want to add QUtf8String until SG16's char8_t gets settled. It'll probably be settled by C++20, which means we can probably work on this during Qt 6 lifetime, possibly even 6.1 or 6.2.

It makes sense to avoid future incompatibilities with the standard but fortunately Qt sometimes chooses to solve real problems ahead in time  ;-)

More information about the Development mailing list