$include_dir="/home/hyper-archives/boost-users/include"; include("$include_dir/msg-header.inc") ?>
From: alexmark (talamar.lands_at_[hidden])
Date: 2006-09-22 06:11:18
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.