[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