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