09.06.2019, 01:26, "Konstantin Tokarev" <annu...@yandex.ru>: > 09.06.2019, 01:02, "Kevin Kofler" <kevin.kof...@chello.at>: >> Giuseppe D'Angelo via Development wrote: >>> In other words, the advantages of keeping the Qt equivalents start to be >>> (seriously) questioned. We're therefore left with the question of what >>> to do with these equivalents. >>> >>> * We could play the catch-up game, but that requires a development >>> investment that is simply not there any more, and is even questionable >>> (is it the job of people developing Qt to rewrite algorithms widely >>> available elsewhere?). >>> >>> * We could move the Qt equivalents into a "support library", maybe with >>> deprecation warnings, maybe without. I'm not sure of the traction of >>> this idea these days, but IIRC having "Qt4Support" was frowned upon when >>> Qt 5 was being shaped. (Thus QtAlgorithms was left in QtCore, deprecated.) >>> >>> * We could just deprecate and tell people to migrate away. That's kind >>> of the whole point of this thread, and comes with all the annoyances, >>> and people reimplementing them downstream because they still want the >>> convenience of a qSort(vector) over std::sort(vector.begin(), >>> vector.end()). >>> >>> * We could keep things where they are, supported, thus offering the >>> easier APIs; but simply reimplement them on top of the "upstream" >>> equivalents. (Ignore the possible ABI break.) >> >> 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. >> >>> Here's where the "extension" bites us: if the Qt equivalent offered >>> something that upstream is not offering, and we can't reimplement it, >>> then what do we do? Dropping support for it would be, at best, an API >>> break; and at worst, a _silent_ behavioural change. >> >> That's why you should just not do that, and instead keep the Qt >> implementation. Let the users decide for themselves whether they prefer the >> advantages of one (Qt) or the other (STL) implementation. >> >> I, for one, don't give a darn about all those new C++11/14/whatever STL >> features. I don't want to touch the STL with a 10-foot pole! The best thing >> Qt can do with the STL is pretend it doesn't exist. (I wish QT_NO_STL were >> still supported!) > > Do you really wish to touch C++ with a ten foot pole? It's such a horrible, > inconsistent, and complicated language! There are many higher-level languages > on market which can make you more productive, and you surely won't need to use > STL. Ever.
Oh sorry, I've forgotten to add a reference: [1] https://yosefk.com/c++fqa/ -- Regards, Konstantin _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
