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
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
