[Development] Qt 5 types under consideration for deprecation / removal in Qt 6
mikhail.svetkin at gmail.com
Wed May 29 20:12:05 CEST 2019
> The implementation of QMutex, and especially QReadWrtieLock is much more
efficient that one of most standard library.
I have run some benchmarks recently and the result did not show the QMutex
was the best.
I published the results here:
On Wed, 29 May 2019 at 19:44, Kevin Kofler <kevin.kofler at chello.at> wrote:
> 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
> write idiomatic Qt code.
> I use QSharedDataPointer a lot, and my code will likely be stuck on Qt 5
> 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
> is that this replacement is dangerous because ranged for does not copy (so
> legacy code that accidentally changed the container, which was harmless
> Q_FOREACH, will crash and burn with ranged for) and can be inefficient
> 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
> 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
> that matter.
> 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.
> Kevin Kofler
> (who thinks C++ is a great language except for its standard
> Development mailing list
> Development at qt-project.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Development