Nonstandard allocator::pointer in containers

[Martin Sebor]

Phil Endecott wrote:
> Dear libstdc++ Experts,
> 
> I'm writing an application that uses shared memory to communicate 
> between processes.  I'd like to be able to store standard containers in 
> this shared memory, but since it can be mapped at different addresses in 
> different processes I need to use offsets rather than pointers.  I seem 
> to have most of this working, but I'm held up by the fact that the 
> standard container implementations explicitly use pointers internally, 
> rather than the allocator<T>::pointer type which I have defined as 
> offset<T>.
> 
> I've asked about this on comp.lang.c++ (e.g. here: 
> http://groups-beta.google.com/group/comp.lang.c++/browse_frm/thread/2c24ad7a7a5cce65/051e738e0f1a8808?hl=en#051e738e0f1a8808 
> 
> and am told that the standard only requires containers to work with 
> allocators that define pointer as T*.  However, other libraries seem to 
> be more generous in what they allow: Dinkumware certainly supports this, 
> and it looks to me as if the newly-open-source Roguewave library does too.

We do, but, AFAIK, it's broken in std::list.

But it seems to me that you'd need more than just user-defined
pointer types to get this to work -- you'd also need stateful
allocator support.

> 
> I'm right at the limits of my understanding of C++ here, and I've no 
> idea if there are serious downsides to this or whether it's just a case 
> of doing a search-and-replace of T* by _Alloc::pointer. 

IIRC, it was a lot more work than just that. With user-defined
pointers you can't make many of the assumptions and optimizations
that you can otherwise. For example, you can't assume that such
pointer types are convertible to true pointers (such as void*),
you might need to be prepared to deal with exceptions where they
normally cannot occur, you can't use memcpy to copy objects of
user-defined pointers, etc.

> But I thought 
> I'd ask here and see what you say.  The alternative seems to be to write 
> my own container class, which is realy not an appealing thought.  (Or 
> maybe I can just paste in the Roguewave one?)

Keep in mind that the tarball on our Web site is a development
snapshot. It's not meant to be a stable release of the library.
That said, if you do play with it we will be interested in your
feedback, including any problems you might encounter. Until the
ASF infrastructure has been set up for the project you can send
your feedback to opensource@roguewave.com.

Martin