Supporting non-standard pointer types in STL containers

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

I'm in the midst of some work to allow the allocator::pointer typedef  
to define custom pointer types (other than T*).  The specific scenario  
that prompted this is my desire to be able to create and use STL  
containers in shared memory regions (e.g. Boost.Interprocess) even if  
different processes have to map the region at different virtual  
addresses.

I wrote up a design document about the effort to create a pointer  
class which is semantically equivalent to a pointer, and the effect  
this has on libstdc++ which I am trying to minimize.
     http://docs.google.com/Doc?id=dhmxp5ht_27dnc34chs

At this point, I've been able to get a pointer type written, which  
along with changes to the bits/std_tree code of version 4.0.0 of  
libstdc++, allowed me to access a map<> from shard memory from  
different virtual addresses.  That proves that this can work, and that  
there may be a reasonable approach to the coding of STL containers  
which allows libstdc++ to support this optional aspect of the  
allocator standard.  You can see/compare this code as follows:

Std_tree.h (modified) - http://stlshm.sourceforge.net/stl_tree.h
Std_tree.h (original) - http://stlshm.sourceforge.net/stl_tree_original.h
Relative_ptr.h - http://stlshm.sourceforge.net/relative_ptr.h

I diff of the two versions of stl_tree.h will show that most of the  
changes were simply to parameterize the pointer type used in the  
implementation.  However, there were some places where some minor  
changes to the code's semantics was needed to resolve ambiguities I  
couldn't otherwise figure out how to address in the pointer  
implementation.

What I'm looking for here is advice or feedback on a number of issues,  
for example, any improvements to reative_ptr<> class that would  
further minimizing he changes needed to libstdc++ to be compliant with  
non-standard pointer types.  Any ideas regarding testing, ongoing  
maintenance, etc.

I would really appreciate the maintainers taking a look at this and  
offering any warnings about this approach which would make it  
unsuitable for libstdc++.  I am trying to determine, for example, if  
I'm negatively impacting the ABI.  (see the design doc.)  I would like  
to ensure that this approach is acceptable as a contribution to libstdc 
++ before making further efforts to roll this change into the current  
releases and expand the scope to cover all the STL container types.

Thanks in advance for any help.
- Bob Walters
Bob dot s dot walters at gmail dot com