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-----
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
> 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)
-----END PGP SIGNATURE-----
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk