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@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.
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
