enabling STL containers in shared memory

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

Hello,

I've a quick question for the owners/controllers of the libstdc++
project.  I've been working on another one of "those projects" which
seeks to put STL containers into shared memory.
(stlshm.sourceforge.net).  I have compound constructs like
map<string,string> working fine, so long as all applications map the
regions at a common address.  The issue I am having with libstdc++
specifically is that many classes internally use native pointers
directly, rather than employing the allocator::pointer typedef and
rebind capability to determine the pointer type of container
instances.  If it did the later, I can get the STL containers to use a
'relative pointer' implementation, and believe it will then work even
when mapped at different addresses.

I noticed recently that the Boost project's interprocess library
addressed this problem by copying the libstdc++ source and just
modifying the necessary elements to make it functional.  i.e. This
reinforces my opinion that the fix is not too hard.

Any chance that we can make these changes part of the std
distribution?  I offer to hunt through the code and identify all
native pointers requiring this kind of transformation in order to
enable the allocator::pointer typedef to function as intended.  I can
then provide patches to this list (or another location)  for inclusion
in the library.

Will these patches be accepted?  I've seen messages in the past
regarding this topic and there seems to have been some disagreement
over whether this change should be made, but I am hoping it was simply
a matter of someone volunteering to do it, rather than requesting that
the libstdc++ team do the work.

Thanks,
- Bob Walters