> -----Original Message----- > From: Thiago Macieira <thiago.macie...@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 ;-) _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
