[Development] HEADS-UP: QStringLiteral

[Mutz, Marc]

On 2019-08-22 15:42, Tor Arne Vestbø wrote:
>> On 22 Aug 2019, at 15:11, Mutz, Marc via Development 
>> <development at qt-project.org> wrote:
>> 
>> 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.
> 
> The notion that developing a generic library is “harder” than
> application development is no excuse for not having good APIs for our
> own internal use. Nor is it an excuse for micro optimising every code
> path “just in case”. A lot of the “library” development in Qt are
> features and convenience, where the availability and ease of use of
> the feature is itself more important to our users than whether or not
> it performs optimally in every single use-case. As long as the API is
> not painting us into a corner the code can in many cases be optimised
> incrementally when and if it turns out to be a problem.
> 
> Qt is a large project, with a wide range of areas. If the mental model
> for developing Qt requires you to take into account every single
> corner case or micro-optimisation possible you’ll end up with 10
> perfect string classes and nothing that uses them because the feature
> development will grind to a halt. This also goes for increasing
> std-ization of Qt, where the use of the std-library ends up
> obfuscating what the code is actually doing.

I'm sorry if I sound blunt, but this is just nonsense. What you call 
optimisation, isn't. Using QStringLiteral or QLatin1String is equally 
readable. As is just using "". Aye, it's more to _think_ and to _write_, 
but we don't care about those metrics. The same goes for QList vs. 
QVector vs. std::vector. Anyone who claims that one is any more or less 
readable than the other is ... to say it politely ... mistaking brevity 
for clarity.

So, given equally-readable alternatives, it behooves every programmer to 
choose the most efficient one. This is what is called "avoiding 
premature pessimisation", it's nothing new, it's not something I 
invented, it's coming up on 25 years of age, at least. And it is not 
optimisation, premature or otherwise. It was Scott Meyers that coined 
the term, though I'm sure good programmers have known this for decades, 
just not under that name.

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.

And, finally, if I hear, once more, implied or explicitly, about how 
wonderfully readable Qt sources are, or "were", implying "before Marc 
came and ruined everything", I _will_ print QBezier::split() in the 5.13 
form and throw it from Frankfurt all the way to Oslo.

Seriously.

Thanks,
Marc