RE: [GD-Windows] new/delete across DLL's
Brought to you by:
vexxed72
From: Jon W. <hp...@mi...> - 2003-03-24 19:06:27
|
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 |