change to use allocator::pointer typedefs

[Bob Walters <bob dot s dot walters at gmail dot com>]

Question for the libstdc++ maintainers:

I’ve been working on some changes to libstdc++-v3 to have those  
containers that take an allocator template parameter make use of the  
allocator::pointer typedef.  This would allow the STL containers could  
be constructed with an allocator which works with shared memory.    
Such an allocator, by using an ‘offset_ptr<T>’ as the pointer type  
rather than the normal T*, could ensure that containers in shared  
memory could function even when mapped into different applications at  
different addresses.  I think this particular desire gets expressed  
every year or so.  For example: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21251

I’m trying to figure out how to make this an acceptable contribution  
to libstdc++. Here’s what I’ve come up with:

(1) First, the changes to the containers will be limited to the use of  
the allocator typedefs, but all development may assume that those  
typedefs are T* and const T*.  It will be the responsibility of the  
person trying to write an alternative pointer implementation  
(offset_ptr<T>) to make sure their implementation works given the  
libraries reliance on standard implicit pointer type conversions.  
(subclass* to baseclass*, T* to const T* when passed to functions,  
etc.)   In other words, no special coding practices to make sure the  
STL containers will work with any particular pointer implementation.   
Because of implicit casing, I had a lot of ‘fun’ trying to make all  
this work with my example offset_ptr<T>, but have managed to get it  
working.  The libstdc++ community doesn’t have to agree to anything  
other than the use of the allocator typedefs within those types that  
are passed an allocator.

(2) As a ‘proof’ that libstdc++ implements this optional (‘encouraged’  
but not mandated) aspect of the C++ standard, I was thinking of  
donating the offset_ptr, along with a modified std::allocator  
implementation which uses it, so that they can optionally be used when  
building and executing the test suite – just to see if the various  
containers compile and run with such an allocator/pointer.  This  
provides an easy way to prove that the library could function with a  
non-standard pointer type.  It also might help anyone trying to  
exploit this quality to have a pointer class implementation to refer to.

Is this acceptable?  Is there anything more that needs to be done to  
make this change acceptable?

 - Bob