Random thoughts on C++ containers: - The major game engines do their own std::vector's, yet it's difficult to find good drop-in std::vector replacements on the web. - As far as I know std::vector can't take advantage of realloc() on trivial types, which seems like an easy win.
6
1
33
- A smart std::vector replacement could use the following info to optimize its auto-grow behavior: The modules/lines it's being called from ("callsite optimization") The element type The current size of the container How aggressively the vector grows (fast vs. slow)
3
0
2
For example, if you see a uint64 vector being created at a certain callsite, and the app always push_back's 256 elements into the container, you can use this history to optimize the container's behavior.
2
0
2
- A good std::vector communicates deeply with the underlying heap implementation. After allocating a block, the vector should immediately query the heap to get that block's *actual* size so it can exploit that entire block's allocation.
3
0
6
Replying to @richgel999
This C++ paper covers this case and exposes it in the allocator: wg21.link/p0401 The rest of your use cases are not handled by the current allocator or vector machinery. You can write a standards-compliant std-vector that does everything you just asked for.

1:55 AM · Jan 17, 2021

1
0
3
I know, because I did, and it passes libstdc++'s tests for vectors:
1
0
3
If I ever get done with the gigantic pile of work in front of me, I plan to release my vector a default allocator to the world and start really building containers that put no-exceptions and drop-in replacement of standard components first: thephd.github.io/freestandin…
0
0
4