|
Boost : |
From: Dave Abrahams (abrahams_at_[hidden])
Date: 2000-05-14 17:07:34
on 5/14/00 8:03 AM, John Maddock at John_Maddock_at_[hidden] wrote:
> 1) The pools destructor enumerates through all the elements and deletes
> those that haven't been deleted - potentially this could be quite an
> expensive operation - it's also breaks std::allocators requirements (see
> below).
>
> 2) The static allocator version (std_pool_allocator I think) uses a static
> member for the pool - this efectively prevents this allocator from being
> used in program startup/exit code - as would happen if you declare a global
> variable using this allocator for example, the normal solution for this
> situation is to use a singleton: boost::singleton anyone?
>
> 3) The allocator requirements permit containers to allocate memory with one
> allocator and free with another un-related allocator (think of list::splice
> for example), in fact the lifetime of allocated memory can be independent
> of that of the allocator, I think this kind of usage would crash your
> allocators (due in part to #1)?
But that was part of my original reason for issuing the pool challenge. I
was never so interested in seeing a pool-based allocator. If these two goals
are in conflict perhaps the approaches should be separated.
-Dave
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk