From: Alberto Barbati (abarbati_at_[hidden])
Date: 2002-11-23 07:09:09
Thanks Steve, for considering my issues.
>>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
Sorry to bother you, I have a few more questions on this topic:
1) from what I understand, the "ordered" property depends on the fact
that allocation and deallocation calls are correctly paired, in the
sense that if I always call free() in the opposite order of the
respective malloc() calls the pool is still considered to be ordered. Is
this right? In this special case, would I get a benefit by calling
2) can ordered_malloc() be called on a non-ordered pool? Does the call
make the pool ordered? In this case, is the complexity still O(1)?
3) can ordered_free() be called on a non-ordered pool? Does the call
make the pool ordered?
4) ordered_malloc() is described as "merges the free list to preserve
order", does this mean that unused, but potentially usable, chunks are
removed from the free list?
I think the "order" property is very useful and powerful, but it's not
terribly clear from the docs how it can be exploited to full potential.
The descriptions of the methods are missing post-conditions that are, in
my opinion, as important as pre-conditions. Change in the "ordered"
state of the pool could be added more explicitly there. Moreover, if a
function can be called on both ordered and un-ordered pools, it would be
interesting to state explicitly if there's a difference in behaviour
Thanks for your patience,
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk