> No-one uses C++ unless they need the extra performance. This is mostly right, though wide portability can be another reason.
This being said, that does not mean that every line of a C++ application needs to be optimized with CPU cycles in mind. In my experience, only restricted portions need to be optimized (desktop application developer here). This is why I use Qt containers when I need convenience, and specialized containers when I need speed. And in that last case, that depend on the context (eg. there are a variery of map implementations, each one with some advantages). If we had a magic stick to switch all Qt containers to the STL library containers, that would not prevent the need to use dedicated containers when speed really matters. Hence, I am fine with today Qt containers. And today, I can quote an example of an important container that Qt provides but that C++20 does not (correct me if I am wrong): QVarLengthArray (even if, here again, they are faster implementations when one (rarely) need move semantics support). Philippe On Fri, 17 May 2019 07:47:55 +0200 "Mutz, Marc via Development" <development@qt-project.org> wrote: > On 2019-05-16 23:41, Konstantin Shegunov wrote: > > you end up where the STL is - so convoluted it's hardly worth making > > anything with it. > > Qt is a C++ library. If you don't like C++, either stay in QML or use > Java. No-one uses C++ unless they need the extra performance. > > It is not Qt's job to change the decisions made by the C++ standards > committee. If you want to change the STL, submit a paper to WG21, not > rant on a Qt mailing-list. > > Thanks, > Marc > _______________________________________________ > 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