Re: [boost] [interprocess] Container requirements for Boost.Interprocess allocators

From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2006-12-29 03:51:35

Mathias Gaunard wrote:
> The boost inteprocess documentation [1] says that all objects must be 
> constructed-destroyed via allocator::construct and allocator::destroy 
> functions when using the interprocess allocators.
> 
> However, according to the draft of the next C++ Standard [2] 20.1.6/2, 
> allocator::construct is strictly equivalent to placement new and 
> allocator::destroy stricly equivalent to a call to the destructor, with 
> the pointer type casted to void*.
> 
> Therefore why is such a requirement necessary?

Basically because the pointer type of Interprocess allocators is not a 
raw pointer, but a relative one (offset_ptr). This way containers using 
allocator::pointer as their pointer type can be mapped by different 
processes, in different base addresses. If you try to do this:

using boost::interprocess;

typedef allocator<MyClass, managed_shared_memory::segment_manager> MyAlloc;

managed_shared_memory mem();

MyAlloc alloc(mem.get_segment_manager());

MyClass *myclass = new(alloc.allocate(1)) MyClass;

you will get a compilation error, because "allocate" returns 
allocator::pointer and that pointer is not MyClass * but 
offset_ptr<MyClass>. You can get the raw pointer from offset_ptr<> using 
offset_ptr<T>::get() method. That's why containers should use 
allocator::construct() that is defined like:

    void construct(const pointer &ptr, const Convertible &value)
    {  new(detail::get_pointer(ptr)) value_type(value);  }

It's conforming for a STL container to ignore allocator::pointer and 
suppose it's a raw pointer, but this sadly can support shared memory or 
any other smart pointer based allocators.

Regards,

Ion