Re: [Boost-users] boost::interprocess::managed_external_buffer class restrictions

From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2006-09-22 10:41:37

alexmark wrote:
> The problem is the class managed_external_buffer currently does not provide 
> public default c-tor and interface functions create(), open(), close().

That interface was considered unsafe in the Shmem review. I agree that 
it's annoying in your case or we you want to store the class as a member 
and you don't want to use dynamic allocation. I plan to add move 
semantics to Interprocess so that you can do:

//Default constructed
managed_external_buffer buf;

void my_create_func()
{
    managed_external_buffer tempbuf(create_only, /**/);
    //All tempbuf resources are moved into buf, and tempbuf
    //will be in default-constructed state
    buf = move(tempbuf);
    //or alternatively
    //buf.swap(tempbuf);
}

I wanted to add these semantics for the next version. I wanted to 
release it next week but I have so many fronts that I don't think I will 
have enough time.

> As a workaround, I wrote my own class "managed_user_buffer" derived from 
> boost::interprocess::detail::basic_managed_memory_impl and providing public 
> default c-tor and create()/open()/close() methods. I just made a copy of 
> managed_external_buffer.hpp and slightly modified the code.
> But it's not so clear, why managed_external_buffer class itself exposes the 
> restricted interface?

Because it isn't fully recycled yet from Shmem ;-) I first did a quick 
hack and not a whole rewrite. You are too fast!

I'm glad you've fond a workaround. This will pressure me to release the 
next Interprocess version with the move semantics.

Regards,

Ion