Re: templates + RTTI + shared library = impossible?
On Jan 30, 6:31 pm, legalize+jee...@mail.xmission.com (Richard) wrote:
James Kanze <james.ka...@gmail.com> spake the secret code
<bf3a79e7-9307-44eb-8b60-4897105cd...@c4g2000yqa.googlegroups.com> thusly:
On Jan 29, 12:27 am, "BGB / cr88192" <cr88...@hotmail.com> wrote:
"Dan Caugherty" <dan.caughe...@gmail.com> wrote in message
similar issues can also manifest in other ways as well:
malloc/free not working between DLL's [...]
This is a purely Windows problem, present probably because
Windows doesn't bundle the CRT DLL's with the OS (I think). [...]
The issue is that each module (DLL or EXE) has its own Win32
heap. Memory allocated by a module will be allocated from
that module's heap and must be freed by code in that module to
be freed from the corect heap.
That's not really an issue for C++ programs, at least those that
are using new, and not the Windows API directly, to allocate
memory. C++ programs don't allocate memory from Windows, they
call the operator new function, which in turn calls malloc.
And malloc is in the CRT library. If the CRT library is in a
distinct DLL, all Windows allocations will be from that DLL, and
will use that DLL's heap. If you statically link a separate
instance of the CRT with each DLL, then each DLL will have a
separate instance of the operator new function and malloc, and
will use its own heap.
The arrangement of using separate system heaps for each DLL
seems like a very poor design decision to me (supposing you're
right---the Windows documentation says that "Each *process* has
a default heap*---, but it doesn't really matter here. Even
with one common system heap, each instance of malloc/free will
use a different set of static variables to manage this heap, and
memory returned by a call to HeapAlloc in one instance of malloc
will not be known in any other instance.
As I said, the motivation for statically linking the CRT is that
it isn't bundled with the OS. If you link with it dynamically,
you either have to require that all systems on which you run
have it installed, in addition to the standard system stuff, or
that you bundle it into your deployment package. (The Microsoft
site has extensive documentation about these issues. I'd
suggest that anyone deploying code written for Windows which
uses DLL's wade through it. I'd also suggest avoiding DLL's in
your own application, if possible, since they do make deployment
more complicated.)
--
James Kanze