[Development] HEADS-UP: QStringLiteral

[Edward Welbourne]

On Tuesday, 20 August 2019 08:56:06 PDT Bogdan Vatra via Development wrote:
>>> Isn't silly to have so many wrappers around a such a simple thing as
>>> strings?

În ziua de miercuri, 21 august 2019, la 00:12:59 EEST, Thiago Macieira a scris:
>> We all wish it were simple. If it were, we would have no need for so
>> many string classes, for Marc's email and even for SG16 (Unicode) to
>> exist in the C++ committee.

To elaborate: designing a good string class Is Hard.

I've seen text-books by academics who cheerfully take on the task as a
nice example that everyone can understand by which to show off how their
language of choice does a fine job of object-orientation.  They
invariably reveal how little they know about the practicalities of class
design in production environments: the results would be slow, hog memory
and fail to work across threads.  All too often it's assumed that making
a few dozen copies of all your data in the course of a single line of
code is inconsequential.

I've worked with several string classes "in industry" that have been
honed to be tolerably efficient.  All come with annoying amounts of
advice one has to remember about how to use them to avoid wanton
allocation of yet more copies of one's data.  All make compromises
between efficiency and ease of use.  Still, they worked better than the
ones the academics proposed.

Furthermore, what this thread is discussing isn't just string classes;
although QByteArray has some inappropriately string-ish features bolted
into it, it's really a *container* class for carrying around a slab of
data.  That this data is often meant to be interpreted as a string
should be the business of some string-view facade on top of it, that the
data container shouldn't care about.  The difference is crucial: a byte
array just contains bytes, without interpretation; by applying some
encoding, other code may interpret it as a string and might even
reasonably use it as the data-store backing a string facade that does
this interpretation; but the byte array isn't a string.

Bogdan Vatra (21 August 2019 11:50)
> You didn't answered my questions :).

I hope the above goes some way towards doing that.

>   The most important one is: can we have *A single* String class and
> *A* single sting wrapper for each UTF-X variant?

Partly because we're where we are and it's hard to change - replacing
QString in all of Qt would be impractical.  However, see above:
designing a Good string class Is Hard.  Asking for nice features that it
should have is easy; and quite quickly constrains it to be almost
impossible to implement, once one actually works out all the conflicting
implications of all the nice features we all want.

>   Personally I'm not going to waste my time learning 10 sting wrappers
> and classes just to make some pico optimizations like:
>
> QString ext = QLatin1String("exe"); // it's terribly wrong and people
> which are doing this mistake must be stoned to death!
>
> QString ext = QStringLiteral("exe"); // it's so good and it will save
> the planet from extinction!
>
> // But
> QString ext1 = QLatin1String("exe") + ext; // it's ok
> // and
> QString ext = QStringLiteral("exe") + ext; // it's a abomination!
>
> // Even more
> QHash<QString, QString> test;
> test[QLatin1String("key1")] = QLatin1String("some text %1").arg(1); // wrong
> test[QStringLiteral("key1")] = QStringLiteral("some text %1").arg(1); // wrong
> again
> test[QLatin1String("key1")] = QStringLiteral("some text %1").arg(1); // still
> wrong
> test[QLatin1String("key1")] = QStringLiteral("some text %1").arg(1); //
> victory !!!

I fail to find a difference between the last two !
But I grant that you have made your point.

> Am I the only one which finds situations silly ? Of course there are
> more examples with the other String wrappers/functions in Qt, but I
> think is enough to show how crazy is the situation.

Yes, it is frustrating and annoying that one has to learn all these
fiddly details and apply them; and yes, it would be nice if there were
one master string class to rule all others, that folk can use when they
don't care too much about efficiency.  Perhaps the answer to that is to
use PySide / PyQt, hence python's string types.

It is frustrating, but it is not silly: it is that way for the sake of
performance and efficiency.  In client code, you can do as you please
and just use QString("whatever") freely.  However, in library code,
those of us who develop Qt have a duty, to clients who *do* care about
performance, to actually think about all these fiddly little
complications, that can have significant impact on code footprint,
run-time memory use and speed.

Returning to your original post:
>>> All the major frameworks out there (i.e. Java, C#) they have a
>>> single String which does all the magic.

Yes, and those systems are all built with the assumption that client
code doesn't care if every single time anything happens to a string a
fresh copy of it is made.  They probably aren't actually that
inefficient, but the basic premise of the design of those easy-to-use
string classes is that if they were it wouldn't matter much.

We don't have that luxury, sad to say,

	Eddy.