[Development] Qt 5 types under consideration for deprecation / removal in Qt 6
mardy at users.sourceforge.net
Thu May 30 10:23:46 CEST 2019
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
> == QScopedPointer -> std::unique_ptr ==
> Suggested by Thiago on
> 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
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
http://www.mardy.it - Geek in un lingua international
More information about the Development