RE: [GD-Windows] new/delete across DLL's

[Jon W. <hp...@mi...>]

Virtual destructor has nothing to do with memory allocation.

Virtual destructor and override of operator new and delete may=20
help a little bit, but you still get into trouble with templates=20
and other inline functions.

Repeat after me: Factories. Interfaces. Bliss. :-)

Un-balanced allocations/deletions really are a bad idea for a=20
variety of reasons; this being just one.

If you link your DLLs and your EXEs against the same runtime DLL=20
then they will share a heap, and things will appear to work,=20
until such time as someone wants to write a plug-in for your app=20
using Borland, or some other version of MSVC, or you want to run=20
a debug plug-in with the release EXE (debug and release MSVCRT=20
libs are not compatible).

And things get worse with MSVCPRT, which is needed for the MS=20
implementation of STL. It suffers all the problems of unbalanced=20
allocations already -- if you implement your own operator new,=20
then some template instances inside MSVCPRT will use the old=20
operator delete anyway, 'cause that's what was in effect when=20
that DLL was built.

Cheers,

			/ h+


> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Grills, Jeff
> Sent: Monday, March 24, 2003 10:49 AM
> To: 'gam...@li...'
> Subject: RE: [GD-Windows] new/delete across DLL's=20
>=20
>=20
>=20
> Assuming C++, shouldn't a virtual destructor be sufficient to solve =
this
> problem?  At the very most, you might have to have the virtual =
destructor
> and overload new and delete per class, but those could trivially=20
> turn around
> and call the global versions.
>=20
> I load our graphics interface from a DLL, and it does allocate memory =
that
> is released from the client.  I've hooked the memory management=20
> functions in
> the DLL to call back into the main game executable so that I really =
only
> have one heap.  My intent wasn't to work around this issue, but rather =
to
> make sure that I had all memory in a single heap so that I could=20
> monitor the
> game's memory usage and fragmentation.
>=20
> j
>=20
> -----Original Message-----
> From: Rich [mailto:leg...@xm...]
> Sent: Monday, March 24, 2003 12:08 PM
> To: gam...@li...
> Subject: Re: [GD-Windows] new/delete across DLL's=20
>=20
>=20
>=20
> In article <E18...@sc...>,
>     Ben Hawes <cr...@ca...>  writes:
>=20
> > in the game exe, I call wibble =3D3D new CFooBar;
> > Later on, within the exe, I call delete wibble; and get an Assert=3D
> >  warning because I'm deallocating from the wrong heap.
>=20
> Yep.  That's the way Windows DLLs work.  Allocations inside a DLL are
> done on the heap belonging to the DLL (because the DLL can live in
> memory longer than your process, it must use its own heap for
> allocations).
>=20
> You can deal with it in one of several ways:
> - use a static library, not a DLL
> - use a helper function in the DLL that does the deallocation for you
>=20
> I'd use a static library unless there really is some overriding
> reason to use a DLL.  "It just works" that way.
>=20
>=20
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=3D555
>=20