On Fri, Jun 26, 2009 at 9:36 PM, Zachary Turner <divisortheory@gmail.com>wrote:
It's a bit late in the thread, but I just wanted to mention that if your executable and DLL both link to the *shared* version of msvcrt (and the same shared version, e.g. mult-threaded debug, single-threaded release, etc) and not the static version of msvcrt, then you should have no problems deleting across dll boundaries. The problem occurs when two different modules have two different copies of the crt and one of those module tries to delete memory allocated by the other module.
The reason you often see windows api calls providing functions like NetApiFreeBuffer, etc is because they are implemented in a single dll (usually kernel32.dll) and there is only 1 copy of that dll on your system, that must work regardless of which version of the crt you link against.
Thanks for elaborating on these facts. I've indeed invested a lot of time researching this information. As you mention, there are a certain number of requirements that must be met in order for deleting across DLL boundaries to function, I prefer to choose the path that works in 100% of all cases, and that is to use factory functions and deleter methods. While this is not as clean, it is more fail safe. On a more philosophical note, I tend to treat deleting across DLL boundaries no different than sending a pointer across a network connection and calling 'delete' from a different computer. In my opinion, it is good general practice to maintain resources in a modular way. Not only does this have a greater chance of functioning, but it also makes the logic clearer and easier to follow. Again, thanks for reiterating these critical points.