[Development] Qt 5 types under consideration for deprecation / removal in Qt 6
giuseppe.dangelo at kdab.com
Mon Jun 10 12:12:04 CEST 2019
On 09/06/2019 00:00, Kevin Kofler wrote:
> There is one option missing:
> * We could just keep the Qt equivalent as is, without adding the features
> of the STL equivalent if there is no manpower to port them to the Qt
> equivalent. Developers using the Qt version are happy with the Qt version
> as is, and those that are not can always go and use the STL. There is no
> point in deprecating or splitting out those classes, they should just
> remain in QtCore where they belong.
There are some practical problems with this:
1) It creates technological debt into QtCore, where we have to keep this
stuff around forever (and working and supported on *all* platforms, and
compatible with the latest compilers, etc.).
2) It creates technological debt all around Qt implementation, where the
"worse" choice (for some factor of worse) may be made, and that's
something a C++ library should never, ever do.
3) It still creates a massive teaching problem (for instance, the
perennial "which one should I use? Qt containers or STL containers? Qt
atomics or STL atomics? Qt smart pointers or STL smart pointers? Qt
mutexes or STL mutexes?" and so on). Unlike what it has been claimed
elsewhere, people now arrive to Qt from all sorts of backgrounds, so
these questions DESERVE accurate answers.
4) The most important one: the moment some of this stuff is exposed as
public API, the users are no longer free to choose. We have
QSharedPointer, QHash, (well, QList), and more stuff and similar in Qt
APIs. That's Qt making the decision for the user, so saying "they can
always go and use the STL" is false.
I know that solving the type exchange at the API level is a much, much
bigger fish to fry. I'm just saying that it IS a compatibility problem
that forces the user's hand.
My 2 c,
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4329 bytes
Desc: S/MIME Cryptographic Signature
More information about the Development