On 29/05/19 13:53, Mutz, Marc via Development wrote: > == QSharedDataPointer / QExplicitlySharedDataPointer == > > These are basically Qt-internals, and should never have been public in > the first place. It's _because_ they are public that we have two of > them, and soon a third one (properly non-public): > https://codereview.qt-project.org/c/qt/qtbase/+/115213 That commit's > message also explains what's wrong with the QSDP and QESDP.
No way :-) I've never used QExplicitlySharedDataPointer myself, but QSharedDataPointer is very useful; it should not be removed in Qt6. And if it gets deprecated, an equally easy to use alternative should be provided. > == QScopedPointer -> std::unique_ptr == > > Suggested by Thiago on > https://codereview.qt-project.org/c/qt/qtbase/+/261553 > > I agree. We now have std::unique_ptr, and it's movable. QScopedPointer > had the problem that it didn't know what it wanted to be: > boost::scoped_ptr or std::unique_ptr. A real scoped pointer would not > offer release(), a unique_ptr would need to provide move semantics. > QScopedPointer has release(), but no moves (were proposed, but not > accepted). I never used release(), and I'm fine if std::unique_ptr is used as the implementation. But the name QScopedPointer is so much better than unique_ptr, that I wouldn't like to see it deprecated. > == QLinkedList -> std::list > (https://codereview.qt-project.org/c/qt/qtbase/+/261421) == > > Of the Qt containers, this one is the most-unused (in Qt code), as well > as the one that's furthest behind it's STL counter-part. Whenever I use > std::list, I use it for splice(), a function that just cannot be added > to a CoW container. Qt is already almost completely QLinkedList-free. > Let's bury QLinkedList. I bet it's unused because everyone is using QList. But once we deprecate QList, people will start asking for a CoW version of std::list. It's not clear to me why splice() cannot be implemented: it would just mean that the list data would detach as in all other non-const methods. Or am I missing something? In general, I agree with the plan to make our classes more interoperable with the STL, but I vote for keeping our own CoW classes and naming conventions. Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
