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