[Development] Views

[Philippe]

>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.

I fully agree with this topic (and kudos for Lakos in general).
That's actually a lack in Qt containers: no allocation customization
possible.

Allocators help a lot, but when it's a matter of maps, there are many
other aspects coming into play.

> QVarLengthArray
> 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.

I don't know why you say there will never be such a standard allocator.
For example, eastl has such a container with custom allocator:
https://github.com/questor/eastl/blob/master/fixed_vector.h#L71
(cf. OverflowAllocator)

There is also a recent c++ proposal:
http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0843r1.html

BTW, this article fails to mention a recent excellent contribution from google
/ abseil
https://github.com/abseil/abseil-cpp/blob/master/absl/container/inlined_vector.h

> There is no readability difference between the use of a Qt container
> and that of an STL container.

I have a different opinion of this. And this is what I mean when I say
that Qt containers are convenient.

Philippe