>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 _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
