On 2019-08-21 14:13, Sérgio Martins via Development wrote:
On 2019-08-20 16:56, Bogdan Vatra via Development wrote:
Hi,
Isn't silly to have so many wrappers around a such a simple thing as
strings? All the major frameworks out there (i.e. Java, C#) they have
a single
String which does all the magic.
We do have a single one that does all the magic: QString. A Qt user
can ignore all others.
Ack.
The difference between Qt and Java or C# is that we also offer
non-allocating alternatives for users who care. And if they care, they
need to learn them.
Another difference is that, in Java at least (or was it JavaScript?),
"foo" _is_ a String (as in "foo".length()). This is decidedly not the
case in C++/Qt. In Java, the compiler can place "foo" into read-only
memory, and it will be an (immutable, as I learned) String instance.
It's probably also the case that all "foo" in the same program are the
same string. All this is, or at least may be, also the case for "foo" in
C++, except that "foo" is not a std::string or QString instance. C++ has
no concept of strings. Only of string literals. "foo" is a const
char[4]. To manipulate it, you need to use malloc/strdup/strcpy, or you
must copy the data into a user-defined class such as std::string or
QString. We can lament this over and over again, but it will not change
the facts. QStringLiteral is an attempt at fixing this: a fully-fledged
QString, but placed in read-only memory, no runtime allocations. The
problem is that the way it's implemented, QStringLiteral("foo") +
QStringLiteral("foo") stores the string u"foo" and its QStringData
header, _twice_ in the executable. And since we globally enabled
QStringBuilder, there's no runtime efficiency difference to
QLatin1String("foo") + QLatin1String("foo") which _will_ store "foo"
just once.
For the case that triggered this discussion, the androiddeployqt
executable, I wouldn't bother with optimizations and just use what's
more readable, even raw strings.
I agree in principle. The problem in Qt code is that it's mostly
library, and making checkers (and reviewers) aware of the type of source
code will be extra work compared to just applying the same rules
everywhere. After all, this is decidedly not optimisation, it's avoiding
pessimisation, and as such, the non-pessimised version of the code
should naturally flow from your fingers. It should take extra mental
work to unlearn the library rules when coding on a tool for once.
And:
Code gets copied: this is from a tool:
https://codereview.qt-project.org/c/qt/qt3d/+/263442/2/tools/qgltf/qgltf.cpp
this was later found in a plugin:
https://codereview.qt-project.org/c/qt/qt3d/+/268271/2/src/plugins/sceneparsers/assimp/assimphelpers.cpp
So while I totally agree that in application code, do as you want, the
advice is not quite so clear-cut for Qt tools, or, in fact, any project
where the same developers are working on a library as well as tools.
Thanks,
Marc
_______________________________________________
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development
