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
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
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…
1:58 AM · Jan 17, 2021
0
0
4


