On 2019-05-17 08:12, Philippe wrote:
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.
There is no readability difference between the use of a Qt container and
that of an STL container. Don't confuse familiarity with
simplicity</stroustrup>. If two things are equally readable (I
emphasize: readable; it doesn't matter that it takes more LOC to code
it, cf. QSpinBox ctor Qt 3 vs. Qt 4), then you should use the more
performant one. And please go back in time and read up on what I wrote
about Q_FOREACH and how it _hurts_ readability.
The Qt containers used to outperform the STL ones on major compilers all
the way into the oughts, but they no longer do and the std containers
have gained a lot of features. Qt has had eight years time to catch up,
and didn't. The focus of Qt lies elsewhere now, and so it should be. But
Qt should realize that and regularly rebase on a C++ version it can
minimally support on all platforms. Currently, that's C++11. A rebase
helps with the interop with other libraries, and tools (tsan, anyone?)
and, something all the oldtimers seem to forget: people who learn C++
_today_ learn unordered_map. They learn std::mutex. They will likely ask
what, then QHash is for and why there's QMutex, but not QRecursiveMutex.
Why Qt classes can be held in std::map, but not in std::unordered_map.
And why they need to learn a different API for containers from the one
they already know.
Qt is building up a tradition. Traditions are good for society, but in
sw development, we call them technical debt, and realize that growing TD
binds resources better spent elsewhere.
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).
While it is true that there's no such container, it's even more true
that there will never be one. Because C++ made the allocators, which
back in the 90s were just a way to handle near and far pointers on older
architectures, fit for actually abstracting allocation. Please watch one
of Lakos' recent allocator's talks for a ton of benchmarks how a custom
allocator helps speed up - not just std::vector but also std::map, if
one is so inclined.
Thanks,
Marc
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
