Ease access to underlying singleton_pool

[Henning.Stroeker@…]

It is not convenient to call singleton_pool<...>::release_memory() if you use pool_allocator or fast_pool_allocator. The reason is that the exact singleton_pool type has to be specified:

typedef boost::pool_allocator<int> myAllocator;
std::vector<int, myAllocator> v;
...  //do something and empty v again
boost::singleton_pool<boost::pool_allocator_tag, sizeof(int)>::release_memory();

In fact the call to release_memory might need even more template arguments (because of user allocators etc). And: The developer has to know all template parameters. If the vector declaration changes the call to release_memory has to be changed too, otherwise it would still compile but have no effect. This is error-prone. It would be much easier if pool_allocator and fast_pool_allocator would provide a typedef for the used singleton_pool. Then the above code would look like this:

typedef boost::pool_allocator<int> myAllocator;
std::vector<int, myAllocator> v;
...  //do something and empty v again
myAllocator::singleton_pool_type::release_memory();

The implementation in pool_alloc.hpp would look like this:

template <typename T,
    typename UserAllocator,
    typename Mutex,
    unsigned NextSize>
class pool_allocator
{
  public:
    typedef T value_type;
    typedef UserAllocator user_allocator;
    typedef Mutex mutex;

    ...

    typedef singleton_pool<pool_allocator_tag, sizeof(T), UserAllocator, Mutex, NextSize> singleton_pool_type;

...

[Steven Watanabe]

I hesitate to add such a typedef because it isn't reliable.

{
std::list<int, boost::pool_allocator<int> > l;
...
}
boost::pool_allocator<int>::singleton_pool_type::release_memory(); // no effect

[John Maddock]

I agree with Steven - the actual type of the allocator used by a container is "unmentionable" - and indeed more than one such type may even be used.

Closing as won't fix.