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

[Mikhail Svetkin]

Well I checked it with MinGW. The result was not so good.

Thank you, I will try to run benchmark with latest MSVC.

Best regards,
Mikhail


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.
>
> Philippe
>
> 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:
>
>    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
>>
>
> _______________________________________________
> 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/32ca9c31/attachment.html>