On 12/05/2020 03.49, Lars Knoll wrote:
* QStringLiteral should turn into a small wrapper around u”…”, and
probably also get deprecated. Maybe we could add a user defined
literal for it instead that returns a read-only QString (QString s =
“…”_q;). So u”…” would lead to a QStringView, u”…”_q to a read-only
QString.
How will this work? As I understand, the main advantage to
QStringLiteral is that it statically encodes the *length* as well as the
data. This isn't possible with raw literals, which are merely
NUL-terminated.
Even std::string wants literals for this reason. A UDL would obviously
be superior, but I don't see us ever getting rid of some form of QString
literal short of templatizing *everything* that takes a T* (for T in
char, char16_t, etc.) to take a T(&)[N] instead.
In most other places we should by default only use QString, unless
there are very significant performance benefits to be had from using
QStringView. This helps us keep an API that’s both easy to use and
maintain. With the ideas above, you can still create a read-only
string, so data copies can in many cases be avoided if required.
Really? How?
The "nice" thing about QStringView is that it does not have ownership;
you have to be careful about how long you hold onto it lest it turn into
a dangling pointer. You can't construct a QString from any old bag of
byt^Wcharacters because a QString is implicitly valid until it is destroyed.
That said, I think I understand the reasoning here; make it up front
that the input is going to wind up in *a* QString. If the user's input
is *already* a QString, the function can make a shared copy rather than
constructing a brand new one. However, it would be nice for such
functions to offer r-value reference overloads for cases where a QString
needs to be created, or if the user is done with their copy. (Actually,
a possibly-owning reference wrapper could be useful here...)
--
Matthew
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
