[Development] Feature Freeze Exception: QStringView

Kevin Kofler kevin.kofler at chello.at
Fri Feb 3 10:59:21 CET 2017


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




More information about the Development mailing list