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