[Development] How qAsConst and qExchange lead to qNN

[Ulf Hermann]

>> 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