Michael Marcin wrote:

Marcus Lindblom wrote:

...

Thomas Witt wrote:

...

There are two open tickets for pool in 1.34.1.

http://svn.boost.org/trac/boost/ticket/284 http://svn.boost.org/trac/boost/ticket/991 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? Cheers, /Marcus

Michael Marcin wrote:

Marcus Lindblom wrote:

...

Michael Marcin wrote:

...

Marcus Lindblom wrote:

...

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

[snip]

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

And that size_t is bound to be much less than what you actually allocate with your pool. I.e, since you're allocating so much you need a pool, its probably so much that the size_t doesn't matter. I'll see what I can come up with. Cheers, /Marcus