...

From what I can gather from the docs, then the required changed to the standard library is quite small; maybe you should consider submitting a defect report that says where the standard must be changed in order to support this style of allocators and allocation?

Rewriting all container classes seems to be a quite big task, so maybe its better to change the standard.

Yes, I agree that would be nice and it is the way to go. Some implementations, such as Dinkum STL use allocator::pointer as pointer type and they have very minor problems compiling this approach. What I want to make clear is that I don't want to reinvent the STL for boost. I was talking to boostify only helper classes so that I could for example write in one process: //----------------------------------------------------------------- //Create shared memory allocator segment shm_named_alloc segment segment.create("/MyShMem", 10000); //Create an array of ints named "MyInts" in shared memory segment "/MyShaMem" int *ptr = segment.named_alloc<int>("MyInts", 10/*allocate an array*/, 0/*ctor parameter*/) //Fill ints for(int i = 0, i < 10){ ptr[i] = i; } std::fill(ptr, ptr+10, 1); And in other process write: //----------------------------------------------------------------- shm_named_alloc segment //Open allocator segment.open("/MyShMem", 10000); //Find "MyInts" int *ptr = segment.named_find<int>("MyInts") //sort std::sort(ptr, ptr+10); //Delete "MyInts" array from segment segment.named_delete<int>("MyInts"); //----------------------------------------------------------------- To get this, I propose a library with the following classes: -> Relative pointer (a new smart pointer). -> shared memory creation class, process shared mutex, process shared reentrant mutex, named semaphore -> shared memory manager class (uses shared memory segment as a pool for allowing malloc/free like operations) -> named shared memory manager (so that the user can store any class associated with a name in the shared memory segment) -> a STL allocator providing shared memory allocator for STL-like containers If someone wants to create its own container can use these elements but I don't plan to repeat all standard containers for boost. But I think that placing classes in shared memory can be interesting for efficient inter-process communication. Maybe I've not explained very well my goals. My article is about STL containers, but my proposal is for placing any object in shared memory and provide some allocators (normal and pooled) so that users can create their own containers if they need that. I hope this explanation can correct my previous post. Regards, Ion

My requirements are (currently) a little simpler that yours (the "clients" of the shared memory segment have read-only access for reading pre-cached data). Like many others I've grown tired of having to do this sort of thing manually!

Michael

I've also talked with Francis Andre who is also very interested in this library for his work. Although so far only two people consider this library interesting, I will present a proposal so that people can see what the library can do. I aim for a simple, small library, targeted for Visual 2003 .NET and gcc 3.4.1 for the moment. If the library is accepted, I will start a port to other systems. So if anyone is not against this, I will present a proposal shortly. First I have to read deeply all steps required for a first version. I am also tired of doing shared memory stuff by hand. Regards, Ion

Hi Ion.

Although so far only two people consider this library interesting.

Actually I'd be most interested in such a library. I at the moment use my own solution for the same problem. I ran into the same trouble you describe in your documentation but did not get a chance to dig in so deep as I had a real-world problem to solve in a real-world time frame :-))). I did create a SharedMemory object which works, together with my SharedMemoryId objects which are actually offset based pointers that can be stored inside the SharedMemory area. (Can't tell you how much I hate it when I get sloppy and store a standard C++ reference in there only to find it is not usable from another process. :-))) My SharedMemoryId objects (actually called RepositoryId and WriteableRepositoryId as the my model is pretty domain specific) use an offset from the start of their SharedMemory area and when you use them you need to specify which SharedMemory object they relate to. I like your design with an offset from their own address much better as that would allow my * and -> operators to not rely on one global SharedMemory object (which was enough in my case). And I guess having a larger generic ptr that can be 0, and a smaller non-null one is a small-enough price to pay (much better than my relying on a global shared memory object when using standard C++ dereferencing operators). I did not implement any smart memory allocation schemes as my shared memory space was only allocated and never needed to be deallocated. I use a placement new operator (as in 'new (someSharedMemoryArea) int(5)') which just stores the object on the next available location in the shared memory area, and the memory allocation information is not shared so only one user allocates the memory after which it allows read-only access only. Unfortunately this also prevents me from directly using any 'smarter' data structures there, like strings or vectors, that sometimes need to reallocate their storage space. As for the standard C++ library containers - I tried the allocator approach and ran into the same allocator problems you encountered. In the end I just needed a list structure so I rolled out my own and made it an STL compatible container so that it can be used with standard C++ library algorithms. Hope you see you're not alone out there... like I thought I was when I did this... :-). If you need any help please just holler... I'll see what I can do... When I get the time I'll try to use your library in my project so you'll have another real-world test user application available (Windows/MS Visual Studio .NET 2003, and will be ported over to *nix/gcc some time next year - so if the library is portable its a major bonus as otherwise I'd have to rewrite my own). Many thanks for all the effort you put in this so far. Certainly looks promising. Best regards, Jurko Gospodnetic