frankly, this is a very overstated problem. It's trivial to write a header with such functions (e.g. https://github.com/OSSIA/libossia/blob/master/OSSIA/ossia/de...). And it's already provided by Boost if you use it.
But since it's not in STL, everyone will use a bit different implementations for something this mundane and common.
why would you call this "broken" ? That's one of the most optimal solutions for reallocations if you append values continuously, since it will reallocate only logarithmically.
Also in that case I might want to grow it by a fixed amount, once it grows past a certain threshold.
It's a shame one needs to write another vector implementation just for that.
To implement a growing allocation , you'll have to create a custom vector, pretty much.
I think it is a valid complaint. Most of time you want to apply something like "find" to the whole collection.
I'd also love to have C++ standard maps (esp. unordered_map) where I only pay for what I use. Namely, due to C++ spec I have to pay for the nodes instead of having a flat, CPU cache efficient, buffer. In other words, a different map type where other items are allowed to move in memory when something is inserted or removed.
Oh, while we're at it, it'd be nice if vectors etc. could realloc instead of allocating a completely new memory region and freeing the old one when more space is required.
A more ergonomic allocator story for specifying alternative allocators would also be very nice for some niches, like when you need to avoid fragmentation or require better performance in embedded development.