[Development] The future of smart pointers in Qt API

[Giuseppe D'Angelo]

Il 03/02/20 20:38, André Pönitz ha scritto:
> Directly affected are for instance functions operating on full containers in
> 
>    https://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.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...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4329 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/development/attachments/20200203/a142b9e2/attachment.bin>