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

[Philippe]

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:
> 
> - https://bugreports.qt.io/browse/QTBUG-71036?focusedCommentId=444244&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-444244
> - 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/e729937b/attachment.html>