[Development] Qt 5 types under consideration for deprecation / removal in Qt 6

[Mikhail Svetkin]

> 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:

   1.
   https://bugreports.qt.io/browse/QTBUG-71036?focusedCommentId=444244&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-444244
   2.
   https://bugreports.qt.io/browse/QTBUG-71036?focusedCommentId=444654&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-444654



Best regards,
Mikhail


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
> 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
> 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
> library)
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190529/da7b7dae/attachment.html>