[boost] pool

From: John Maddock (John_Maddock_at_[hidden])
Date: 2000-05-14 07:03:02

Steve,

>The new pool is in the vault.  It contains some macros and classes that
may,
in the future, go in other libraries (such as BOOST_POSTULATE and ct_gcd).
It depends on shared_ptr and type_traits.
<

Looks like this is getter there, however, there are a couple of issues I
spotted:

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

4) The allocators aren't thread safe - this is very important from my point
of view, but opens up a whole can of worms you may not want to get into.

5) It would be nice to see some performance comparisons between the pooled
allocators and std::allocator/operator new - there are two obvious tests:
(1) memory recycling - lots of allocations but obly a few blocks committed
at one time, and (2) a large allocation - lots of blocks committed at once
and then freed at once.

- John.