> 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.kof...@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@qt-project.org > https://lists.qt-project.org/listinfo/development >
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
