Marc Mutz wrote:
> The question of whether to replace QString sink arguments with QStringView
> ones is an open one. It does not affect the usefulness of QStringView as a
> way to pass UTF-16 data from a wide variety of sources through a single
> function.
>
> I'd invite you to look at the QColor port to QStringView
> (https://codereview.qt-project.org/184038) to see for yourself, but past
> experience has left me with the feeling that it'd be pointless...
I had actually already looked at that patch, but looking at it again, it is
true that it at least avoids the deep-copy issue because setColorFromString
is a template that takes any string type. If, on the other hand, it would
take a QString, or it would take a QStringView, but then have to store the
string persistently (which means it needs to be converted to QString or
something equivalent to remain valid), we would get an extra deep copy. I am
not sure how many contexts can be safely changed as in your patch. But even
the way it is, there may still be a loss of efficiency in the common case
where what is passed is a QString, depending on what the compiler inlines,
whether the wrapper with the QString argument is compiled in or not, etc.
> PS: Still waiting for your promised patch to port QToolBox and/or
> QDataWidgetMapper away from QList...
I never promised such a patch and you know that. Please stop repeating that
nonsense over and over.
Whoever wrote the broken code should be expected to fix it.
Kevin Kofler
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
