So, if the method immediately converts whatever it gets to QList or
QString, then there is no point in passing it a span or view.
My point is that there _is_. Citing my blog post:
callConsumeQStringHelloWorld():
> [...]
That's the worst case scenario of passing an 8bit string literal to a
function that takes a QString. We have QStringLiteral to avoid the 8bit
to 16bit conversion, but I know there are more problems with that.
Now lets look at the case of passing a pre-existing QString (i.e. one we
don't have to create in place) to a function taking QAnyStringView and
storing the result as QString.
// somewhere:
QString a;
void setter(QAnyStringView view) { a = view.toString(); }
// elsewhere:
QString foo;
[ ... modify foo ... ]
setter(QAnyStringView(foo));
That's a deep copy. A deep copy of a string is obviously more expensive
than the overhead of calling the QString ctor and dtor. Which case is
more common? And by what factor?
I can't say what case is more common. What I can say is that the risk of
creating deep copies sounds worse to me than the risk of calling the
QString ctor and dtor too often.
This is what I mean with "fuzzy". We don't really have the data to
support a move to QAnyStringView for all of our API.
best regards,
Ulf
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
