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

[Grills, J. <jg...@so...>]

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 turn around
and call the global versions.

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 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 monitor the
game's memory usage and fragmentation.

j

-----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 



In article <E18...@sc...>,
    Ben Hawes <cr...@ca...>  writes:

> in the game exe, I call wibble =3D new CFooBar;
> Later on, within the exe, I call delete wibble; and get an Assert=
>  warning because I'm deallocating from the wrong heap.

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).

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

I'd use a static library unless there really is some overriding
reason to use a DLL.  "It just works" that way.