Date: 2002-11-22 13:45:11
> -----Original Message-----
> From: Alberto Barbati [mailto:abarbati_at_[hidden]]
> 1) purge_memory() does not reset the member next_size
Yes, this is in fact a bug, and it will be fixed.
> 2) the name release_memory() confuses me. It makes me think that all
> memory is being released, a task accomplished by purge_memory(). I think
> a better name could be release_unused_memory(). This function also
> should reduce the value of next_size, for example by considering the
> size of the largest block left in the pool.
The current name will remain, for backwards compatibility. Does anyone else
want a "release_unused_memory" alias?
And it will also be updated to change next_size in a manner similar to the
way you describe.
> 3) I would like to have a function to free the entire pool _without_
> releasing the memory. The rationale for this is in the example above.
> Most probably, the number of objects allocated in each iteration of my
> application is almost the same. At the end of an iteration, I would like
> to free all allocated objects with one single call (as I have thousands
> of objects, it makes the difference) yet it's a waste of time to free
> the memory, because I will need the same amount again in the next
> iteration. Such function could be called free_all_chunks() or
> something similar.
This should certainly be possible, and sounds reasonable; I'll look into it.
> 4) what's the use of ordered_alloc/ordered_free? I made a few tests and
> they are indeed a bit slower than regular alloc/free, without any
> apparent advantage. Am I missing something?
Keeping the free list ordered allows algorithms that traverse the free list
along with the memory owned by pool to work correctly/more efficiently:
1) array allocations will be more efficient (pool_allocator keeps its free
list ordered, whereas fast_pool_allocator does not)
2) release_memory() will work correctly
3) object_pool uses the ordered property to efficiently implement the
automatic destructor calls for allocated objects
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk