-----Original Message----- From: John Harris [mailto:john.harris@tradingtechnologies.com]

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