On 2020-06-24 09:32, Marc Mutz via Development wrote:
[...]
2) the complexity is already there and QAnyStringView helps in
reducing
it:
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
QAnyStringView:
- https://codereview.qt-project.org/c/qt/qtbase/+/305402
(QVersionNumber)
- 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
- QXmlStream
- 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,
like QLatin1String.
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
code anyway
- QSettings
- QUrl/Query, Network headers
- possibly QFont::fromString(), but that one is just weird (not a static
function)
- 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.
Thanks,
Marc
_______________________________________________
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development
