Re: pool_allocator problems on VC7.1 (real rele ase)

From: scleary_at_[hidden]
Date: 2003-04-25 10:33:02

> -----Original Message-----
> From: John Harris [mailto:john.harris_at_[hidden]]
> 
> I can test this for you tomorrow (I'm about to go drinking now).  In 
> return, could you possibly tell me how to change pool_allocator so 
> that it uses my own tag?  My goal is to have a totally local 
> allocator for some special parts of the code.  Why, BTW, does it have 
> to use the Singleton pool interface instead of the object pool 
> interface?  The latter, I think is what I'm after.

I'm going to start with a brief overview of the Boost.Pool interfaces:
  pool<> (pool.hpp): "The" pool interface.  Provides allocation and
deallocation of memory.
  object_pool<> (object_pool.hpp): Restricts access to the pool<> interface.
Provides allocation and deallocation of memory for a single object type;
and, when destroyed, will call the destructor for any non-deallocated
objects allocated from that object_pool.
  singleton_pool<> (singleton_pool.hpp): Provides access to the pool<>
interface as a singleton, distinguished mainly by size of the memory
allocations and a tag.
  pool_allocator<> (pool_alloc.hpp): Restricts access to the
singleton_pool<> interface.  Provides a Standard-compliant Allocator
interface.

To answer the specific questions:
1) The pool_allocator<> (and fast_pool_allocator<>) can be relatively easily
extended to use other tags for the singleton_pool<> interface underlying
them - pass an additional template parameter (after the UserAllocator
parameter), defaulting to the currently-used tag.  This is a good idea, and
I'll put it in when I can.
2) pool_allocator<> uses the singleton_pool<> interface instead of the
object_pool<> interface for the following reasons:
  A) Standard Allocators only handle the allocation and deallocation of
memory, and do not deal with actual object types [+].  The intent of
object_pool<> is to cleanly call destructors for objects that were never
deallocated.  Such an action: 1) is unneeded (since all containers should
free whatever memory they allocate, and destroy any objects they construct),
and 2) would cause the Allocator to get into construction/destruction
semantics, which is contrary to the Standard Allocator concept.
  B) Standard-compliant Allocators that can be used with STL-provided
containers must be stateless.  This requires an underlying singleton
interface.  Encapsulating a non-singleton interface within the Allocator, or
even sharing one with the handle/body idiom does not satisfy the stateless
requirement.

[+] The object-related Allocator requirements (construct()/destroy()) do not
have anything to do with allocation/deallocation, and are generally
considered to be a useless overspecification.

Please let me know if I haven't been clear enough - I've been a little
lacking in sleep lately ;)

        -Steve