> Sent: Monday, January 21, 2019 at 9:51 AM > From: "Arnaud Clère" <arnaud.cl...@minmaxmedical.com> > To: "Allan Sandfeld Jensen" <k...@carewolf.com>, "development@qt-project.org" > <development@qt-project.org> > Subject: Re: [Development] Qt6: Adding UTF-8 storage support to QString > > > -----Original Message----- > > From: Allan Sandfeld Jensen <k...@carewolf.com> > > > > On Dienstag, 15. Januar 2019 19:43:57 CET Cristian Adam wrote: > > > Any chance of having UTF-8 storage support for QString? > > > > > Use QByteArray when you can. > > I think a QUtf8String class derived from QByteArray would help a lot making > this happen in the real world! > 1. It would be found more easily by users in need of a utf8 encoded dynamic > string > 2. It would allow making the encoding explicit (QString or QUtf8String or > QLatin1String) in newer Qt APIs or user-defined ones, and even totally safe > if disabling const char * casts is possible > 3. It would allow adding QString-like APIs (like setNum(), simplified(), > etc.) over the time without cluttering QByteArray > > Moreover, I have a specific use-case where QByteArray args are used as binary > data (say CBOR) and a specific Utf8String is useful to handle utf8 encoded > args without always encoding/decoding to utf16. > I might not be the only one...
Feel free to burn this suggestion with fire, but what about: typedef QSymbolSequence<QLatin1Char> QLatin1String; typedef QSymbolSequence<QRawChar> QByteArray; typedef QSymbolSequence<QUtf8Char> QByteArray; typedef QSymbolSequence<QUtf16Char> QString; So they can have the same API? It really seems to me that the issue is storage, not that they need a different API to operate on the storage. _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
