Re: [boost] [utility] new auto_buffer class --- RFC

Subject: Re: [boost] [utility] new auto_buffer class --- RFC
From: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2009-03-02 14:01:44

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