[Development] Qt 5 types under consideration for deprecation / removal in Qt 6
mikhail.svetkin at gmail.com
Wed May 29 20:41:05 CEST 2019
Well I checked it with MinGW. The result was not so good.
Thank you, I will try to run benchmark with latest MSVC.
On Wed, 29 May 2019 at 20:37, Philippe <philwave at gmail.com> wrote:
> For Windows, I am sure QMutex wins (with Visual Studio 2017).
> Not only I got much better figures, but tracing the assembly code of
> QMutex vs std::mutex shows you why QMutex is better. Easy to check.
> In release mode of course.
> On Wed, 29 May 2019 20:12:05 +0200
> Mikhail Svetkin <mikhail.svetkin at gmail.com> wrote:
> > 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:
> Best regards,
> 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
>> 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
>> 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
> Development mailing list
> Development at qt-project.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Development