boost::interprocess::managed_external_buffer class restrictions
The problem is the class managed_external_buffer currently does not provide public default c-tor and interface functions create(), open(), close(). I'm writing DLL, where I need a global object of type managed_external_buffer. This object is "connected" to mapped view of paging file within processing of DLL_PROCESS_ATTACH and disconnected at DLL_PROCESS_DETACH like that: HANDLE g_hfm; LPVOID g_buf_base_addr; managed_external_buffer g_buf; BOOL APIENTRY DllMain(,,,. ULONG reason, ...) { switch (reason) { case DLL_PROCESS_ATTACH: if (!Attach()) return FALSE; break; case DLL_PROCESS_DETACH: Detach(); break; } return TRUE; } bool Attach () { ... g_hfm = CreateFileMapping(0xFFFFFFFF, ...); // use paging file g_buf_base_addr = MapViewOfFile(g_hfm, ...); g_buf.create(g_buf_base_addr, ...); ... MyObj* p = g_buf.construct(...); ... } void Detach () { ... g_buf.destroy_ptr(p); ... g_buf.close(); UnmapViewOfFile(g_buf_base_addr); CloseHandle(g_hfm); ... } 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? I suppose the class would be more usable w/o the restrictions like that. Or not? Moreover, in boost::shmem::named_shared_object class this functionality was available. Thanks, Alex.
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
participants (2)
-
alexmark
-
Ion Gaztañaga