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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk