marc.mutz at kdab.com
Wed Jun 24 10:03:16 CEST 2020
On 2020-06-24 09:32, Marc Mutz via Development wrote:
>>> 2) the complexity is already there and QAnyStringView helps in
>>> https://codereview.qt-project.org/c/qt/qtbase/+/303483 (QCalendar)
>>> https://codereview.qt-project.org/c/qt/qtbase/+/303512 (QColor)
>>> https://codereview.qt-project.org/c/qt/qtbase/+/303707 (arg())
>>> https://codereview.qt-project.org/c/qt/qtbase/+/303708 (QUuid)
I should note that apart from the above, I'm aware of the following
QtBase APIs outside string classes that would require porting to
- QtJSON (no idea what the status of this is - will it be removed?)
- QCbor (possibly; no idea what it is, except something like QtJSON)
- QDate/Time/QLocale format strings and number parsing
- QTextStream / QDataStream
- QtTest (compare functions)
That's not too much.
We also need to come up with a strategy for storing Q*View in QVariant,
We have several other APIs that would benefit from QAnyStringView:
- QObject::setObjectName() - almost exclusively passed literals
- QRegularExpression's pattern - ditto, and pattern is compiled into
- QUrl/Query, Network headers
- possibly QFont::fromString(), but that one is just weird (not a static
- any fromString() and lookup APIs elsewhere in Qt
These are just off the top of my head. There's probably more.
Another, much more complicated issue (but we have that now) is hashing.
We have mixed-type equality, but the hash functions don't agree. This is
pre-existing, but a variant string type exacerbates the issue. The only
fix atm is to = delete qHash(QAnyStringView) because it's not
meaningfully (ie. consistently) implementable.
More information about the Development