Re: [GD-Windows] new/delete across DLL's
Brought to you by:
vexxed72
From: brian s. <pud...@po...> - 2003-03-24 19:51:12
|
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. > > |