This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Nonstandard allocator::pointer in containers


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>.

At a quick first glance, it does look like this shouldn't be too hard, in particular there doesn't appear to be too many uses of raw pointers in vector (5 I think), and actually very few in the rest of the standard containers as well (except in valarray, which I have no intention going anywhere near..)

Out of interest, I assume at the moment the code simply fails to compile? The only minor worry I have is that some code might have a different type for allocator::pointer, and so by changing all the _Tp* to allocator::pointer we could break binary compatability. Since such code is however almost certainly doing what it should be doing, this might not be fatal however...

If you want a challenge, try having a stab at changing it yourself, it looks like it should be fairly easy, and you already have the experience with writing your own allocators to write a simple one to pop into the testsuite :) If you don't have the time to attack the source to libstdc++, email back and I'll have a poke when I have a while (unless someone else beats me to it)

Chris


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]