[geeks] Win32 malloc/free internals, and a unix question.

[Tom Borton]

> > the executable, there is absolutely guarantee that the .DLL gets
>
> Don't you mean "absolutely no guarantee"?
>
Umm, yeah.  Guess you're just a bad influence.

> > linked against the same library - be it static or dynamic - as any
> > executable that might choose to link to the .DLL.  If the
> application
> > is statically linked, fuhgetaboutit, unless the debug symbols were
> > included so that the .DLL could look for the right
> function.  If they
> > both use the same dynamically linked malloc, you're fine, but
> > otherwise you're in serious trouble.
>
> Well, it doesn't say anything about malloc and new using different
> mallocs, so I must have remembered that part incorrectly.
Since I'm too lazy to research it at the moment, this is a bit of a guess, but
I believe that the biggest difference is that new()/delete() have different
versions depending on whether you're using the MFC, ATL, or neither.  A lot of
the MFC and ATL classes are transparent wrappers that don't have any local
storage beyond the window handle (which, for the MFC, is stored internally in
a hidden structure so that the MFC can clean up "windows" after all the object
references have disappeared).  So new and delete actually do nothing in those
cases.  If they have to allocate memory, they use malloc/free.

> The short of it is, when writing Win32 C programs, use the DLL to free
> the resources it gave you.  And hope that the DLL writer isn't doing
> anything naughty with resources you hand it.  And it also points out
> other things that can be done to prevent problems.  But nothing is a
> panacea.
<pendantic>
As a general rule, dynamically allocated storage should always be de-allocated
within the same scope that it was allocated.
</pendantic>
Sorry, I've just finished arguing with a programmer who doesn't understand
that rule, even when the debugger reports unreleased memory.  Grrr...

Tom