[Development] Qt 5 types under consideration for deprecation / removal in Qt 6
kevin.kofler at chello.at
Wed May 29 19:42:32 CEST 2019
Mutz, Marc via Development wrote:
> == QSharedDataPointer / QExplicitlySharedDataPointer ==
> These are basically Qt-internals, and should never have been public in
> the first place.
Why? They are essential to be able to implement one's own CoW types and thus
write idiomatic Qt code.
I use QSharedDataPointer a lot, and my code will likely be stuck on Qt 5 or
6 forever if they get removed resp. deprecated in Qt 6.
> == Q_FOREACH -> ranged for loops
> (https://codereview.qt-project.org/c/qt/qtbase/+/147363) ==
As I already wrote when Q_FOREACH was deprecated to begin with, the problem
is that this replacement is dangerous because ranged for does not copy (so
legacy code that accidentally changed the container, which was harmless with
Q_FOREACH, will crash and burn with ranged for) and can be inefficient with
CoW types if done carelessly because ranged for does not automatically
constify the container (whereas Q_FOREACH made a const copy).
> === related: Q_FOREVER -> for(;;) ===
This just reduces readability for no maintainability gain whatsoever.
> == Java-style iteration
> (https://codereview.qt-project.org/c/qt/qtbase/+/262344) ==
The Java-style iterators are much more convenient to use than the STL-style
ones, and quadratic loops can be accidentally written with both.
> == QScopedPointer -> std::unique_ptr ==
> == QLinkedList -> std::list
> == qHash() -> std::hash ==
> == MT plumbing ==
> === QAtomic -> std::atomic ===
> === QMutex / QReadWriteLock -> std::*mutex* ===
> === QMutexLocker -> std::unique_lock ===
> === QWaitCondition -> std::condition_variable(_any) ===
> == QQueue / QStack -> std::queue, std::stack ==
> == QSharedPointer / QWeakPointer -> std::shared_ptr/weak_ptr ==
> == QSet / QHash -> std::unordered_set/map ==
> == QMap -> std::map ==
All these have the same issue: You are proposing to deprecate Qt types in
favor of STL types, which have a different naming convention (_ vs. camel
case) and often terse, harder to understand names (e.g., ptr vs. Pointer,
push/pop for a queue vs. enqueue/dequeue, etc.), and which do not support
CoW (all the container types in your list), nor Java-style iterators, for
I think Qt should keep striving for completeness and not require its users
to mix&match Qt and STL usage with all the STL's ugliness.
(who thinks C++ is a great language except for its standard library)
More information about the Development