[Development] HEADS-UP: QStringLiteral
Konstantin Tokarev
annulen at yandex.ru
Thu Aug 22 01:56:51 CEST 2019
22.08.2019, 02:39, "Kevin Kofler" <kevin.kofler at chello.at>:
> André Pönitz wrote:
>> Traditionally, "ease of use" and "consistent API" have been a core values
>> of Qt, even consciously bought at the cost of some bytes and some cycles.
>>
>> Of course, this has meant that in certain parts of certain types of
>> applications Qt could not sensibly be used. Still, in most cases all, or
>> almost all of the code could be "plain Qt", benefiting for creation and
>> maintenance from those values. I do believe this was a sensible setup for
>> Qt, and I do think there's room for a general purpose framework living
>> that compromise also in today's world.
>>
>> During the last years (ok, let's say, starting around \epsilon A.J. -
>> "After Jasmin") this promise has been more or less silently broken, once
>> by "leaf" modules deviating, partially intentionally, from previous naming
>> conventions, then for real accidents that couldn't be corrected due to
>> too-late discovery and compatibility promises, and finally by attempts to
>> provide "high performance" alternatives in some places.
>>
>> In the end we lost uniform, easy-to-use interfaces, and the performance
>> gains are only present in very isolated areas of the offering with long
>> stretches in-between, hidden by obscure and continuously changing do's and
>> don'ts so that they are effectively not visible in real-world GUI-centric
>> applications.
>
> The creeping STLization of Qt (deprecating some classes for STL
> alternatives, using STL classes in some APIs, etc.) is also part of this
> disturbing trend. It typically regresses both ease of use and API
> consistency in the name of the holy performance cow.
If you don't need performance, don't use C++. For example, consider Qt for Python.
--
Regards,
Konstantin
More information about the Development
mailing list