enbling STL containers in shared memory

[Jonathan Wakely]

Hi Bob,

>  I would like to know if I can make a contribution to the libstdc++ library.

Anyone can :-)
If it's a significant piece of work (and this would be)  you'll need
to fill out copyright assignment forms so that the FSF will accept
your contributions into the GCC codebase.

> Specifically, I would like to see the STL containers, including
> basic_string, adopt the convention of using the allocator::pointer typedef
> (via rebind, as needed) to determine the pointer type used internally.
>
>  I'm curious on whether that has ever been ruled out in the past.  I've seen
> threads that resisted the idea, but noting really specific.

see http://gcc.gnu.org/PR21771 and the thread it references, particularly
http://gcc.gnu.org/ml/libstdc++/2005-05/msg00300.html and
http://gcc.gnu.org/ml/libstdc++/2005-05/msg00372.html

>  I have "another one of those" projects that seeks to create STL containers
> in shared memory segments (stlshm.sourceforge.net) , requiring a 'relative
> pointer' approach for cases where programs can't all map the shared region
> in at the same virtual address.  I think that the libstdc++ library would
> work correctly if it could be made to honor the allocator::pointer typedef
> for those containers which take an allocator template parameter.

Yes, but unfortunately it's not as simple as just replacing all uses
of T* with allocator<T>::pointer

>  If I do the work of hunting down the native pointers that need to be
> changed, test the changes, and preset patches, would they be accepted?  Is
> there any other reason (e.g. compatibility with odd compilers) that this
> change can't be made?

I don't speak for the maintainers, but if you can make it work then I
think a lot of people would want to see it in libstdc++ :-)

Jon