Hi,
In light of a recent attempt to re-introduce QStringLiteral, relacing
QLatin1String, I'd like to remind everyone that QStringLiteral has a lot
of drawbacks and should not be used unless it saves a memory allocation.
Drawbacks include:
- doubled storage requirements (2 bytes/char) over a L1/US-ASCII string
- unsharability with C strings (each QStringLiteral contains a new
lambda, lambdas have unique types, static data in token-for-token
identical lambdas is duplicated, merging these violates the standard)
- introduction of QString dtor calls (cannot be optimized away)
Anti-patterns include: Using QStringLiteral in
- comparisons (includes relational operators, indexOf, contains)
- composition (QStringBuilder, append, prepend, arg() (now partly
available on QStringView and QLatin1String, too)
- lookup and, I believe, even insertion, in JSON and soon CBOR classes
- debug statements (we prefer debug code to be compact, not fast)
- arguments to any other function overloaded QStringView or
QLatin1String
Alternatives to QStringLiteral:
- u"..." (→ QStringView)
- QLatin1String
Please take note of the following recent developments:
- arg(string, ...., string) ("multiArg") is available now on QL1S and
QStringView
- number formatting isn't, yet
- You can use u"..." in Qt sources unconditionally
- converts implicitly to QStringView
- To convert QString → QStringView, prefer qToStringViewIgnoringNull()
when you don't need to distinguish between the null and the empty state.
It saves a branch.
Please help spreading this knowledge in review and your own work.
Thanks,
Marc
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
