Il 03/02/20 20:38, André Pönitz ha scritto:
Directly affected are for instance functions operating on full containers inhttps://doc.qt.io/qt-5/qtalgorithms-obsolete.html
Just to set the record straight, the main reason why qAlgorithm(begin, end) as well as qAlgorithm(container) have been deprecated altogether, rather than simply have their implementation replaced with std::algorithm() calls, was the fact it would've been source incompatible.
For instance: qSort internally uses calls to qSwap and qLess. An user overloading or specializing them would have had their algorithms broken by the mere replacement towards std::sort (which instead uses an ADL-found swap() + std::swap, and std::less).
So, for the record, if you want to point the finger against the deprecation/removal of these algorithms, please point it against the decision of making the Qt 4 algorithms _diverge_ from upstream, then noticing that Qt cannot or shouldn't catch up with the significant improvements happening upstream, then realizing that a direct port isn't doable because of the diversion. I have already said that having different behavior from from upstream is a terrible idea in this very thread, and the algorithms example is an excellent one.
Now, we may disagree on the extent of the incompatibility -- in the end, who would override qSwap, specialize qLess, and so on? Can't we just bite the bullet and break those rare usages rather than forcing everyone to port away?
As the one who did the porting work, then I get the privilege to say: no, we can't; this is a gratuitous and very hidden source-incompatible change, and the promise of Qt 4->5 was to keep them at a minimum. (And, I don't like them.) So, keep using the deprecated qAlgorithms if you want, throughout the entire Qt 5.x lifetime, with the same Qt 4.x semantics; they still work just like before. _Port_ to the std:: equivalents at your earliest convenience (no, you cannot do a mere s/qAlgorithm/std::algorithm/ in the general case; it's a full port).
Other people are free disagree with this. (For instance, in Qt 6 the decision (which I disagree with) was to introduce similar gratuitous and very hidden source-incompatible changes, e.g. with QList and QHash both breaking iterator stability. I am nowhere near those changes :-))
Indirectly, standard containers have no direct equivalent of .contains(), so advocating using std over Qt has a similar effect here.
I've never proposed replacement of Qt containers in favour of Standard Containers, though. The times we discussed interoperability was for scenarios like "uses internally" (e.g. QHash implemented using std::unordered_map internally). That would've meant keeping the richer Qt container API (indexOf, contains, etc.)
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: Firma crittografica S/MIME
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
