Boost logo

Boost :

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:
> 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?


Boost list run by bdawes at, gregod at, cpdaniel at, john at