<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=ISO-8859-1" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 11.00.10570.1001"></HEAD>
<BODY>
<DIV>For Windows, I am sure QMutex wins (with Visual Studio 2017).</DIV>
<DIV>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.</DIV>
<DIV>In release mode of course.</DIV>
<DIV> </DIV>
<DIV>Philippe</DIV>
<DIV> </DIV>
<DIV>On Wed, 29 May 2019 20:12:05 +0200</DIV>
<DIV>Mikhail Svetkin <<A 
href="mailto:mikhail.svetkin@gmail.com">mikhail.svetkin@gmail.com</A>> 
wrote:</DIV>
<DIV> </DIV><!--CITE-->
<BLOCKQUOTE 
style="PADDING-LEFT: 1ex; BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex">
  <DIV dir=ltr>
  <DIV>> The implementation of QMutex, and especially QReadWrtieLock is much 
  more <BR>efficient that one of most standard library.<BR></DIV>
  <DIV><BR></DIV>
  <DIV>I have run some benchmarks recently and the result did not show the 
  QMutex was the best.</DIV>
  <DIV>I published the results here:</DIV>
  <DIV>
  <OL>
    <LI><A 
    href="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=444244&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-444244</A>
    <LI><A 
    href="https://bugreports.qt.io/browse/QTBUG-71036?focusedCommentId=444654&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-444654">https://bugreports.qt.io/browse/QTBUG-71036?focusedCommentId=444654&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-444654</A><BR></LI></OL></DIV>
  <DIV><BR></DIV><BR clear=all>
  <DIV>
  <DIV class=gmail_signature dir=ltr data-smartmail="gmail_signature">
  <DIV dir=ltr><SPAN style="FONT-SIZE: 12px">Best regards,</SPAN><BR 
  style="FONT-SIZE: 12px"><SPAN 
  style="FONT-SIZE: 12px">Mikhail</SPAN><BR></DIV></DIV></DIV><BR></DIV><BR>
  <DIV class=gmail_quote>
  <DIV class=gmail_attr dir=ltr>On Wed, 29 May 2019 at 19:44, Kevin Kofler 
  <<A href="mailto:kevin.kofler@chello.at">kevin.kofler@chello.at</A>> 
  wrote:<BR></DIV>
  <BLOCKQUOTE class=gmail_quote 
  style="PADDING-LEFT: 1ex; BORDER-LEFT: rgb(204,204,204) 1px solid; MARGIN: 0px 0px 0px 0.8ex">Mutz, 
    Marc via Development wrote:<BR>> == QSharedDataPointer / 
    QExplicitlySharedDataPointer ==<BR>> <BR>> These are basically 
    Qt-internals, and should never have been public in<BR>> the first 
    place.<BR><BR>Why? They are essential to be able to implement one's own CoW 
    types and thus <BR>write idiomatic Qt code.<BR><BR>I use QSharedDataPointer 
    a lot, and my code will likely be stuck on Qt 5 or <BR>6 forever if they get 
    removed resp. deprecated in Qt 6.<BR><BR>> == Q_FOREACH -> ranged for 
    loops<BR>> (<A 
    href="https://codereview.qt-project.org/c/qt/qtbase/+/147363" rel=noreferrer 
    target=_blank>https://codereview.qt-project.org/c/qt/qtbase/+/147363</A>) 
    ==<BR><BR>As I already wrote when Q_FOREACH was deprecated to begin with, 
    the problem <BR>is that this replacement is dangerous because ranged for 
    does not copy (so <BR>legacy code that accidentally changed the container, 
    which was harmless with <BR>Q_FOREACH, will crash and burn with ranged for) 
    and can be inefficient with <BR>CoW types if done carelessly because ranged 
    for does not automatically <BR>constify the container (whereas Q_FOREACH 
    made a const copy).<BR><BR>> === related: Q_FOREVER -> for(;;) 
    ===<BR><BR>This just reduces readability for no maintainability gain 
    whatsoever.<BR><BR>> == Java-style iteration<BR>> (<A 
    href="https://codereview.qt-project.org/c/qt/qtbase/+/262344" rel=noreferrer 
    target=_blank>https://codereview.qt-project.org/c/qt/qtbase/+/262344</A>) 
    ==<BR><BR>The Java-style iterators are much more convenient to use than the 
    STL-style <BR>ones, and quadratic loops can be accidentally written with 
    both.<BR><BR>> == QScopedPointer -> std::unique_ptr ==<BR>> == 
    QLinkedList -> std::list<BR>> == qHash() -> std::hash ==<BR>> == 
    MT plumbing ==<BR>> === QAtomic -> std::atomic ===<BR>> === QMutex 
    / QReadWriteLock -> std::*mutex* ===<BR>> === QMutexLocker -> 
    std::unique_lock ===<BR>> === QWaitCondition -> 
    std::condition_variable(_any) ===<BR>> == QQueue / QStack -> 
    std::queue, std::stack ==<BR>> == QSharedPointer / QWeakPointer -> 
    std::shared_ptr/weak_ptr ==<BR>> == QSet / QHash -> 
    std::unordered_set/map ==<BR>> == QMap -> std::map ==<BR><BR>All these 
    have the same issue: You are proposing to deprecate Qt types in <BR>favor of 
    STL types, which have a different naming convention (_ vs. camel <BR>case) 
    and often terse, harder to understand names (e.g., ptr vs. Pointer, 
    <BR>push/pop for a queue vs. enqueue/dequeue, etc.), and which do not 
    support <BR>CoW (all the container types in your list), nor Java-style 
    iterators, for <BR>that matter.<BR><BR>I think Qt should keep striving for 
    completeness and not require its users <BR>to mix&match Qt and STL usage 
    with all the STL's ugliness.<BR><BR>        Kevin 
    Kofler<BR>        (who thinks C++ is a great language 
    except for its standard 
    library)<BR><BR>_______________________________________________<BR>Development 
    mailing list<BR><A href="mailto:Development@qt-project.org" 
    target=_blank>Development@qt-project.org</A><BR><A 
    href="https://lists.qt-project.org/listinfo/development" rel=noreferrer 
    target=_blank>https://lists.qt-project.org/listinfo/development</A><BR></BLOCKQUOTE></DIV></BLOCKQUOTE><!--/CITE--></FONT>
<DIV> </DIV></BODY></HTML>