-- [ Picked text/plain from multipart/alternative ] Oh my god. I'm such a fool! How did I not notice that?! I should NOT be a C++ programmer with schoolboy errors like that. Thank you, you have just opened my eyes :D haha.
Seriously though, good catch, that really didn't occur to me! On Jan 11, 2008 10:33 PM, Jeremy <[EMAIL PROTECTED]> wrote: > -- > [ Picked text/plain from multipart/alternative ] > I could be reading this wrong, but with this > > *The pointers for this constructor are retrieved > from a class called CItemData which loads all items from a data file into > a > CUtlVector<CItem*> before the call to new CInvItem. The CInventory > destructor calls delete on all m_vItems elements, before emptying the > > *are you saying that 2 vectors both share pointers to the same objects? > > J > * > vector. The CItemData destructor does the same for its vector of CItem*.* > > On Jan 11, 2008 1:55 PM, Minh <[EMAIL PROTECTED]> wrote: > > > ooh.. someone just got ownucted. > > > > just kidding :) > > > > ----- Original Message ----- > > From: "Yahn Bernier" <[EMAIL PROTECTED]> > > To: <[email protected]> > > Sent: Friday, January 11, 2008 1:26 PM > > Subject: RE: [hlcoders] CUtlVector<*>... Memory management? > > > > > > > Well, when talking about a "destructor" the colloquial term is > > > "destructed". > > > > > > YMMV. > > > > > > Yahn > > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] On Behalf Of Jed > > > Sent: Friday, January 11, 2008 1:03 PM > > > To: [email protected] > > > Subject: Re: [hlcoders] CUtlVector<*>... Memory management? > > > > > > [pendantic englishman] > > > > > > *eye twitch* - its "destroyed" not "destructed". > > > > > > [/pendantic englishman] > > > > > > On 11/01/2008, Yahn Bernier <[EMAIL PROTECTED]> wrote: > > >> If the element type is a pointer: > > >> > > >> CUtlVector< CMyClass * > vecStuff; > > >> > > >> Then the underlying object will not be destructed, just the slot > > > holding > > >> the ptr. > > >> > > >> If you do: > > >> > > >> CUtlVector< CMyClass > vecStuff; > > >> > > >> Then the object gets desctructed (but you also have to worry about > > >> implementing a copy constructor or operator =, etc. etc.) > > >> > > >> Safest thing in the CUtlVector< CMyClass * > case is to loop through > > > the > > >> objects and call delete on each entry, and then call Purge/RemoveAll > > > to > > >> free the memory used for the raw pointers. > > >> > > >> ~CUtlVector will automatically clean up the ptrs, but if you don't > > >> delete the objects in the CUtlVector< CMyClass * > case then you'll > > > have > > >> a leak. > > >> > > >> Yahn > > >> > > >> -----Original Message----- > > >> From: [EMAIL PROTECTED] > > >> [mailto:[EMAIL PROTECTED] On Behalf Of Ronny > > >> Schedel > > >> Sent: Friday, January 11, 2008 11:50 AM > > >> To: [email protected] > > >> Subject: Re: [hlcoders] CUtlVector<*>... Memory management? > > >> > > >> Why you don't look at the code itself? In "Remove" you can see the > > >> element > > >> will be destroyed by the Destruct function. The Destruct function > > > calls > > >> the > > >> Destructor of the element. > > >> > > >> Best regards > > >> > > >> Ronny Schedel > > >> > > >> > > >> > -- > > >> > [ Picked text/plain from multipart/alternative ] > > >> > Am I right in assuming that if you have a vector of pointers, that > > >> point > > >> > to > > >> > things you create with "new", you have to either call delete on > each > > >> > element > > >> > or use PurgeAndDeleteElements()? Because that's what I've been > using > > >> up > > >> > until recently, where it seems that trying to delete elements from > a > > >> > pointer > > >> > vector on destruction of whatever they are members of just causes > > > the > > >> game > > >> > to crash with a memory error. Removing the calls to delete stop the > > >> crash, > > >> > but unless CUtlVector automatically cleans up your memory for you, > > >> won't > > >> > this just create MASSIVE memory leaks? As far as I knew, > CUtlVector > > >> > didn't > > >> > magically look after your memory for you... was I wrong? > > >> > > > >> > J > > >> > -- > > >> > > > >> > _______________________________________________ > > >> > To unsubscribe, edit your list preferences, or view the list > > > archives, > > >> > please visit: > > >> > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > >> > > > >> > > >> > > >> _______________________________________________ > > >> To unsubscribe, edit your list preferences, or view the list > archives, > > >> please visit: > > >> http://list.valvesoftware.com/mailman/listinfo/hlcoders > > >> > > >> > > >> _______________________________________________ > > >> To unsubscribe, edit your list preferences, or view the list > archives, > > > please visit: > > >> http://list.valvesoftware.com/mailman/listinfo/hlcoders > > >> > > >> > > > > > > _______________________________________________ > > > To unsubscribe, edit your list preferences, or view the list archives, > > > please visit: > > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > > > > > _______________________________________________ > > > To unsubscribe, edit your list preferences, or view the list archives, > > > please visit: > > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > > > > > _______________________________________________ > > To unsubscribe, edit your list preferences, or view the list archives, > > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > -- > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > -- _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
