[Development] Views

[Mutz, Marc]

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