[Development] The future of smart pointers in Qt API

[Иван Комиссаров]

I would also like to add the argument about templates. Qt API is still incompatible with STL in some places, so one cannot write a template function that simply calls STL variant.
For example:
QString foo;
if (std::empty(foo)) // oops, fails to compile because QString misses the .empty() method

Of course, in the user code we can just call .isEmpty()… but if we’re writing a template function that accepts QString and std::vector, what should we call?
Note that std::string misses .isEmpty() method, so there’s simply no common subset that can be used. Ofc, one can check if .size() is 0, but I guess more examples can be found (that’s the one I was annoyed with).

The other example that comes to my mind is Q_DECLARE_PRIVATE - not very long ago one could not use it with std::unique_ptr because it required the .data() method in a smart pointer. And again, QScopedPointer::get() was introduced only in 5.11 (!!) - I guess the same time when Q_DECLARE_PRIVATE was fixed for std::unique_ptr.

So supporting STL API is very important to be able to write generic code.

> 2 февр. 2020 г., в 00:12, Giuseppe D'Angelo via Development <development at qt-project.org> написал(а):
> 
> Changing the interface in any way which are incompatible with the Standard counterparts is a _terrible_ idea. It kills the principle of least surprise; it makes such facilities incompatible with the STL counterparts, preventing interexchange of data and code; and come Qt (N+1), it will prevent a clean pass of s/QtFoo/std::foo/g over the codebase.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20200202/4c4b60db/attachment.html>