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.dang...@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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
