[Development] HEADS-UP: QStringLiteral

Thiago Macieira thiago.macieira at intel.com
Thu Aug 22 23:00:47 CEST 2019

On Thursday, 22 August 2019 08:39:07 PDT Mutz, Marc via Development wrote:
> And QLatin1String and QStringLiteral are of Trolltech's making. Go to
> the internal history and go discuss with the original authors. From my
> pov, they solved and still solve particular needs. Those needs don't
> overlap, and they also don't overlap with simple "" or u"", so a
> programmer should be able to learn when to use which one. This isn't
> rocket science.


QLatin1String is of Trolltech's making, it's from Qt 4.0 time. But it really 
came about because KDE during Qt3 days had a lot of

#define L1S(x)	QString::fromLatin1(x)

QLatin1String was required because in 3.x and 4.x QString's constructor used 
the *locale* codec, not a fixed codec. The locale codec is slow, since we 
factored out to iconv in 4.x. We don't know what it does, so we can't optimise 
it. It could even be one of the Asian not-exactly-ASCII compatible (where the 
backslash is ¥ or ₩).

That meant the following did work on all Unix we developed on (not Windows), 
but could fail in the field:
	QString degree("\xc2\x80");	// U+0080

With 5.0, we switched to UTF-8 as the codec for the QString constructor, so  
you can write the above code and it will be what is expected.

But QLatin1String is retained because on 5.0, the UTF-8 codec was much slower 
than the Latin1 one. The SIMD-optimised  UTF-8 codec didn't come until later.

QStringLiteral is a 5.0 invention, so it's not Trolltech anymore. I'm the one 
who created that, so it's a hybrid of Nokia / Intel :-)

It was a very good solution given what we knew in 2011 and 2012 and the 
experience that was available with C++11 Unicode strings at the time. Now we 
know better and we know how to make it better. For Qt 6, it is possible (and 
is still my goal[*]) to make creating a QString out of a QStringView and 
through it from a u"" literal happen in constant time, inlined, with no memory 
allocation. A QStringView of such is a pair:
	{ m_size: N, m_data: PTR }
a QString created from this QStringView would be:
	{ m_size: N, m_data: PTR, d: nullptr }

[*] Unless we decide that QString always points to heap memory to avoid the 
plugin-unloading issue.

Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products

More information about the Development mailing list