Re: [GD-Windows] new/delete across DLL's

[brian s. <pud...@po...>]

Whoa, nellie! 

I think people need to be careful when they use the word "heap" in this 
discussion.  The heap that can't be shared is the statically linked C 
runtime heap - those data structures are allocated per DLL/EXE and 
memory allocated from one C runtime heap can't be freed by another.  
Imagine that you passed a pointer from a linked list into the remove 
routine of another linked list and you should get the picture.  
Confusion (at best) results.

The dynamically-linked C runtime solves some of these problems, assuming 
you can be sure that all your code uses the same version of the 
MSVCRT*.DLL - but as Jon points out there's more than one flavor of that 
DLL, so you'll probably end up in hell anyway once you alloc from one 
flavor and free from another.

A Windows heap doesn't have these issues.  The data structures for the 
Windows heap are stored once *per process* in the single instance of 
Kernel32.dll that's mapped in your process.  So you could implement 
operator new globally by just inlining it as GlobalAlloc or 
HeapAlloc(GetProcessHeap()...).  It might not be the most 
space-efficient allocator for small blocks, but it's perfectly 
functional...and why should you PC guys and gals care about running out 
of memory, you've got VM. :) 

Finally, DLLs (and memory allocated in them by your process) do NOT 
survive the death of your process.  How can they?  The DLL is a part of 
your process.  The code might still be mapped into memory if another 
process is using it, but when the process goes down, the data segment of 
the DLL that your process was using goes bye-bye.  Remember, the real 
problem with mixing allocations is because a separate C runtime heap is 
maintained in each module that statically links the C runtime.

--brian

p.s. If I wanted to avoid this problem, I would do exactly what Jon said.

Rich wrote:

>In article <005b01c2f233$ede559c0$7b02000a@mcaf.local>,
>    "Javier Arevalo" <ja...@py...>  writes:
>
>  
>
>>If both the EXE and your DLL link with the MSVC DLL runtime, it will work
>>correctly because all allocations are physically performed inside the
>>(single instance of the) runtime DLL.
>>    
>>
>
>I don't think this is true.  Its not a matter of what runtime you use,
>its a matter of where you perform the allocation.  We used the DLL
>runtime and had the exact same sort of issue reported by the original
>poster.  Putting the deallocation inside the DLL via a helper function
>fixed the problem.  However, the specifics are a fuzzy memory at this
>point.  The one thing I remembered was that allocations performed by
>DLL code are allocated from a distinct heap.  It has to be this way
>for the memory dynamically allocated by a DLL to survive the death of
>your process.
>  
>