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

Subject: Re: [boost] [utility] new auto_buffer class --- RFC
From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2009-03-02 13:40:54

-----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.

> 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkmsKDcACgkQ5vihyNWuA4UfhgCbBgOEfKBj0NfwOLkN4qWJDK7i
VzEAn2jIWCgFD/0aIozvqovfOW0z+up3
=GOub
-----END PGP SIGNATURE-----