[Development] HEADS-UP: QStringLiteral

[Mutz, Marc]

On 2019-08-22 14:48, Martin Smith wrote:
> Now that we use clang in Creator and QDoc, suppose we write a QString
> source code analysis tool using clang. The tool would parse sources
> looking for uses of QString and then analyzing the code patterns where
> QString is used to find possible optimizations using the other Qt
> string classes.
> 
> The output is a report suggesting the possible optimizations. Then we
> can tell customers to write code with QString first, because that's
> easy. When it works, run this tool and see where you can improve
> performance and which string classes to use.

Yes, that tool is called Clazy :)

Please note that I, the thread starter, never claimed that users should 
need to know all about QL1S, QSL, QSV, ... but Qt developers should. I'm 
totally fine with users writing


   QHash<QString, QString> map;
   map["one"] = "uno";
   map["two"] = "due";
   ~~~

At the same time, I find that this is utterly unacceptable in library 
code, ie. Qt implementation.

We need to collectively understand that implementing a library is 
different from the library's API and from use of the API. Anyone who 
thinks otherwise is invited to have a look at qmetatype.h or 
qtypeinfo.h. All users see from this is Q_DECLARE_METATYPE, and we don't 
really care whether they use Q_DECLARE_TYPEINFO. But a Qt developer 
mustn't forget to add Q_DECLARE_TYPEINFO, because it's a BiC change to 
add it afterwards, and there are tons of Qt optimisations hinging on 
getting that correct. Qt developers are under very different constraints 
than Qt users, and we can't go on pretending that it's ok to develop Qt 
as if we were developing a throw-away Qt app and that profiling will 
show us where to optimise.

We can't profile all Qt applications out there, so the chance is high 
that _some_ Qt implementation will be a bottleneck for _someone_. And if 
that someone can't work around our slowness, they will use a different 
tool, or will have to write their own. If they succeed in doing so 
without a huge invest of resources, they will ask us: "if it was so easy 
to make this 50% faster, why did I have to do this, why isn't this in Qt 
already"? No-one can seriously want that.

So, I'm really disappointed, and I'm not intending to single you out 
here, Martin, but it seems to me that well-meaning emails regarding Qt 
_implementation_ are hijacked and transformed into discussions about Qt 
_API_. We should have these discussions, both of them, but we mustn't 
conflate these two very different aspects.

Thanks,
Marc