From: Michael Marcin (mike_at_[hidden])
Date: 2007-06-02 12:55:41
Marcus Lindblom wrote:
> Michael Marcin wrote:
>> Marcus Lindblom wrote:
>>> Thomas Witt wrote:
>>>> There are two open tickets for pool in 1.34.1.
>>> I looked at 284, but I couldn't decide which value to set next_size to
>>> in purge_memory() (which, I believe, is the correct way to fix this).
>>> I.e. whether to:
>>> * Just use the default value (32).
>>> * Add a new member variable to the class, initial_size, and use that.
>>> I think I can present a patch for either, I'm just not sure what the
>>> best approach is. (I was sort of hoping for the lib author to emerge
>>> and provide guidance.)
>> How about something like
>> bool purge_memory( size_type new_next_size = 32 );
> Yeah. That would work, but... I'd like to leave the interface unchanged
> and just fix the bug, if possible.
> #2 is probably the best way to solve it, since it won't require users to
> specify the initial size in several places.
> The argument against it is that it adds another variable to the class,
> but that might not matter much as pool objects are rare and not copyable
> (I think).
> What do you think?
Sorry didn't see this earlier.
I don't know... there are lots of use cases for pool (like some of my
work) that never call purge_memory. I'm not too keen on paying for
features I don't use. Then again its just a size_t.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk