Jump to content
  • Advertisement
Sign in to follow this  
CProgrammer

multiple dlls and memory management

This topic is 5412 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

My project consiosts of multiple dlls. Id s it necessary to call a set of new and delete calls in the same dll or can this be done between dlls. -CProgrammer

Share this post


Link to post
Share on other sites
Advertisement
If your dlls use the same version of the dll version of the CRT (C runtime library) you can free objects allocated in one dll in another dll because there is only one heap between them. If you the the statically linked version of the CRT then you much delete the memory in the same dll as each .dll has a different heap.

Oops, posted too fast. I usually use the multi-threaded dll version of the CRT (/MD) for release mode and multi-threaded debug dll (/MDd) for debug mode in my C++ projects so I can new and delete freely across libraries.

Share this post


Link to post
Share on other sites
Quote:
Original post by CProgrammer
My project consiosts of multiple dlls. Id s it necessary to call a set of new and delete calls in the same dll or can this be done between dlls.

-CProgrammer


It can be done between DLLs and your process because all the DLLs are mapped into your address space, though there are restrictions/caveats:

1) Use the DLL version of the C runtime library. If you use the static library version, then each thing which links with that library will have its own CRT memory heap.

2) The deallocator must be in exactly the same version and type of C runtime library as the allocator was. So for example, if the allocation was made in a DLL which was linked with the "Debug Multi-Threaded DLL" CRT from MSVC++ 7.1, then the de-allocation *MUST* be made from code which was also linked with "Debug Multi-Threaded DLL" CRT from MSVC++ 7.1 - mixing versions won't work, mixing types won't work, mixing debug and release won't work.


Together, those restrictions can be a pain - personally, if I have a DLL export which can allocate memory, I *always* have an export to free that memory. I prefer the symmetry too :o)


The alternative of course is to use your own memory manager (or someone elses such as Paul Nettles') and put that in a DLL and use the Win32 Heap* functions to get the initial block.


[EDIT: too slow by an age]

Share this post


Link to post
Share on other sites
Actually could someone elaborate a bit more on point 1). Im not sure what you mean.
dll1 is statically linked to dll2. Both have code generation Multithreaded.

Share this post


Link to post
Share on other sites
Quote:
Original post by MauMan
Oops, posted too fast. I usually use the multi-threaded dll version of the CRT (/MD) for release mode and multi-threaded debug dll (/MDd) for debug mode in my C++ projects so I can new and delete freely across libraries.


Hello,

I'm not sure this is true (and I'm pretty sure that you do all your allocation/deallocation in the correct DLL): the release delete() is very different from the debug delete(). The debug() delete perform some basic bound checking validation and may assert if it finds something bad (the infamous "damage after block" or "damage before block"). Therefore, it may try to read memory before and after you memory block if you allocated this with a release new(). Now, if you use the release delete() after a debug new() then the release delete() my not function properly - for the same reason in fact: the pointer you gave him is not the pointer to the real beginning of the allocated block.

For multithreaded vs. single threaded; you may have some problems with the thread context (especially when using MFC, which defines its own new/delete operators and use the thread context to store some important informations).

Quote:
Original post by CProgrammer
Actually could someone elaborate a bit more on point 1). Im not sure what you mean.
dll1 is statically linked to dll2. Both have code generation Multithreaded.


No, this is a language abuse - although I also use these word to describe the same thing. You don't statically link 2 dll (they are still dlls). The link is done at load time. see this post (shameless plug) for more information about this (the subsequent nmi post gives more accurate wording to name the different kind of linking).

Quote:
Original post by S1CA
1) Use the DLL version of the C runtime library. If you use the static library version, then each thing which links with that library will have its own CRT memory heap.


From my poor understanding of the CRT, it means that if you allocates some memory in DLL1 (which is statically linked with the CRT) then it will not be allocated in the same heap than the memory you allocated in DLL2 (which is also statically linked with the CRT). Therefore, DLL1 is still responsible for the deallocation of the memory it allocated (the same goes for DLL2).

And as of today my english is just as poor as my understanding of the CRT :| (GIVE ME A PREVIEW BUTTON !!!!)

Anyway, HTH,

Share this post


Link to post
Share on other sites
Quote:
Original post by Emmanuel Deloget
Quote:
Original post by MauMan
Oops, posted too fast. I usually use the multi-threaded dll version of the CRT (/MD) for release mode and multi-threaded debug dll (/MDd) for debug mode in my C++ projects so I can new and delete freely across libraries.


Hello,

I'm not sure this is true (and I'm pretty sure that you do all your allocation/deallocation in the correct DLL): the release delete() is very different from the debug delete(). The debug() delete perform some basic bound checking validation and may assert if it finds something bad (the infamous "damage after block" or "damage before block"). Therefore, it may try to read memory before and after you memory block if you allocated this with a release new(). Now, if you use the release delete() after a debug new() then the release delete() my not function properly - for the same reason in fact: the pointer you gave him is not the pointer to the real beginning of the allocated block.

[Content Deleted]


Sorry, I did not mean to imply that you can mix debug and release DLLs . The point I was trying to make is when given the chance I use those CRT libraries to so that my release project has one consistent heap and my debug project has one consistent heap. It helps keep me sane and helps make the code more portable.

Share this post


Link to post
Share on other sites
Quote:
Original post by MauMan
Sorry, I did not mean to imply that you can mix debug and release DLLs . The point I was trying to make is when given the chance I use those CRT libraries to so that my release project has one consistent heap and my debug project has one consistent heap. It helps keep me sane and helps make the code more portable.


Oh you don't have to be sorry :) I didn't understood you, that's all. Your solution is the only safe one: it will prevent any allocation/deallocation mix. This is (obviously (I like this word)) the way to go.

Regards,

Share this post


Link to post
Share on other sites
There is a really simple way to avoid bugs:
He who allocates it, deallocates it. That means, that if you allocate the memory in one DLL, then that DLL should deallocate it.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!