Re: [boost] [ptr_container] ptr_vector across DLL boundaries

Subject: Re: [boost] [ptr_container] ptr_vector across DLL boundaries
From: Robert Dailey (rcdailey_at_[hidden])
Date: 2009-06-26 23:59:52

On Fri, Jun 26, 2009 at 9:36 PM, Zachary Turner <divisortheory_at_[hidden]>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.