Frank Mori Hess skrev:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Monday 02 March 2009, Thorsten Ottosen wrote:
where v.resize() should never actually shrink the buffer. (Do we need another function that does that?), or should we simply rename v.resize(n) to v.ensure_capacity(n).
I believe the usual way std::vector handles this is that resize() never reduces capacity, and if you do want to reduce capacity you have to swap your vector with a newly constructed one. Hmm, your auto_buffer doesn't support swap though.
No. As it might be O(n). I'm not against providing "swap()", it should just be under a different name, e.g. liniear_swap().
But as the example above shows, we do not need a growing push_back() here. If the name push_back() is problematic, then I'm all for just calling it something else. But I don't like adding a growing push_back() unless we have a use-case.
I'm using it in Boost.Signals2 to hold tracked shared_ptrs during signal invocation. During before invoking each slot, I need to hold shared_ptrs to all the slot's tracked objects. So I store them in a std::vector which has a custom allocator that uses the stack as long as the vector size doesn't exceed 10, then falls back to heap allocation. So before each slot is run, the vector of tracked objects is cleared and the tracked objects from the next slot are pushed onto it. if all the slots in the signal's slot list have 10 or less tracked objects, no allocations occur. But it can also handle slots with large numbers of tracked objects.
Ok, but can you determine the size of the buffer in advance, so you can call reserve? -Thorsten