Am 23.05.20 um 03:06 schrieb Thiago Macieira:
On Thursday, 14 May 2020 07:41:45 PDT Marc Mutz via Development wrote:
There's only our own lazyness which stands in the way of this better
alternative.
[snip the rest]
Update:
As we're reviewing the changes Lars is making to get rid of QStringRef, Lars,
Marc and I came to the conclusion that QUtf8StringView is required for Qt 6.0.
That's because some methods that previously returned QStringRef now return
QStringView and to retain compatibility with:
if (xml.attribute("foo") == "bar")
where QXmlStreamReader::attribute() returns QStringView, we really need to
capture that "bar" as a UTF-8 string and we ought to have optimised UTF-16 to
UTF-8 comparisons. So we're working on it.
If it had been wrapped in QLatin1String(), there would be no compatibility
issues, as there already is an operator==() for QStringView/QLatin1String.
There are currently no conclusions on QUtf8String and QAnyString, nor on what
the APIs should look like.
This also needs a solution in the other direction, QXmlStreamWriter:
This is painfully slow, despite UTF-8 XML, UTF-8 source code (element
names, attribute names) and data which might be used as - or transformed
to - UTF-8 directly. Everything needs to go to UTF-16 first (QString),
and then back to UTF-8. Allocations, Reference counting, no SSO...
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
