Reputation: 135
Resolved: well after few experimentations it seems to be possible.
I was wondering if it's possible to avoid the common cross-dll allocation/deallocation issue by having a memory manager coming along overloaded memory functions (new, delete, delete[], malloc()... ) and responsible for any allocation/deallocation that can occur anywhere in the program, thereby ensuring consistency.
Let's say a.dll contain the memory manager, with something like:
class EXPORT MemoryManager
{
static void* Allocation( size_t uiSize );
static void Deallocation( void* pAllocated );
};
inline void* operator new( size_t uiSize )
{
return MemoryManager::Allocation( uiSize );
}
inline void operator delete( void* pAllocated )
{
MemoryManager::Deallocation( pAllocated );
}
And anywhere else, including b.dll:
int* piDummy = ExternalDllFunctionCallingNew();
delete piDummy;
Would it solve the problem ?
Upvotes: 0
Views: 714
Reputation:
You may be misunderstanding the problem. The problem isn't just several DLLs, the problem is mixing different memory managers. Specifically, problems occur when a the allocator used to free some block is distinct from the allocator which originally allocated that block. One common problem is the two allocators expecting different metadata layout (e.g. where the size of the block is stored). Your "solution" just adds another memory manager to the mix, so it only adds more possibilities for allocation and deallocation being done by different memory managers. Edit: If you can enforce that all memory allocation and deallocation uses your memory manager which is confined within a single DLL, it will probably work just fine. However, as Hans Passant noted in the comments, if you can enforce that you can most likely also enforce that all components use the same CRT version.
DLLs are only associated with this problem because most memory allocation happens via memory managers provided by the C or C++ run time, and those commonly differ (even more so than the rest of the run time libraries) depending on how the DLL was compiled. You can successfully allocate and deallocate across DLL boundaries if you're careful, and you can get similar problems within a single DLL.
Upvotes: 1