[boost] [move] [container] requirements on allocator template parameter

Subject: [boost] [move] [container] requirements on allocator template parameter
From: Jeffrey Hellrung (jhellrung_at_[hidden])
Date: 2009-09-30 12:17:06

Hey Ion,

It would be nice if the boost.container classes rebound the allocator 
type you specify as a template parameter for you, especially since, many 
times, STL containers end up using a rebound allocator "under the hood" 
that is implementation-defined, so specifying an allocator with a 
value_type matching the container's value_type doesn't really buy you 
anything.  I'm guessing this isn't required by the standard, but it 
looks like your container classes are a strict extension of what the 
standard requires anyway, and it seems like we wouldn't lose any 
functionality by auto-rebinding.

For vector, for example, I'm thinking something along the lines of

template< class T, class Allocator >
struct vector
{
     typedef Allocator allocator_type;
     typedef typename allocator_type::template rebind<T>::other 
stored_allocator_type;
     typedef typename stored_allocator_type::value_type value_type;
     typedef typename stored_allocator_type::reference reference;
     /* ... etc. ... */

     vector(const allocator_type& alloc)
         : m_stored_alloc(alloc)
     { /* ... */ }

     /* ... */

     allocator_type get_allocator() const { return m_stored_alloc; }
     stored_allocator_type& get_stored_allocator() { return 
m_stored_alloc; }
     const stored_allocator_type& get_stored_allocator() const { return 
m_stored_alloc; }
private:
     stored_allocator_type m_stored_alloc;
};

That is, the constructor argument and result of get_allocator are 
precisely what the client specified by the Allocator template parameter, 
while stored_allocator_type is what's actually used.

Is there a good argument against doing this?

- Jeff