Which is especially true for the server side of your game/mod. It's likely to be running constantly for days/weeks/months even a year and if you allocate and never release your memory your going to end up slowing and eventually crashing the server.
The "let windows deal with it approach" is just plain bad programming practice. - Jed On 11/01/2008, Tom Leighton <[EMAIL PROTECTED]> wrote: > Newer versions of windows do, im sure that Windows 9x had memory issues > where it was ESSENTIAL you free'd memory you allocated. However, now > windows manages each apps memory (Virtual Memory Addressing), and it > will free any memory you allocated but didn't delete. > > The reason you should still use delete is that your program will start > to become slow/sluggish, etc. Performance reasons. > > Jed wrote: > > Well its C++ so I always thought it was a case that you *have* to > > properly release any memory you allocate. I usually stick a debug > > header at the top of all my code files so if theres any memory leaks > > it'll tell me where they are when the program exits. > > > > - Jed > > > > On 11/01/2008, Jamie Femia <[EMAIL PROTECTED]> wrote: > > > >> -- > >> [ Picked text/plain from multipart/alternative ] > >> That's what I'd like to know.. I'm not totally convinced that it's safe to > >> just leave stuff in the memory.. perhaps a member of Valve staff can > >> confirm? > >> > >> On Jan 11, 2008 6:28 PM, Minh <[EMAIL PROTECTED]> wrote: > >> > >> > >>> -- > >>> [ Picked text/plain from multipart/alternative ] > >>> hmm.. I've gotten way with just calling > >>> RemoveAll() on my CUTLVectors. > >>> Then when I add new elements, I believe it just overtakes the existing > >>> memory addresses of these previous elements that were in the vector. Mind > >>> you, my utlvectors typically never grow to be more than 20 elements. > >>> > >>> When Half-Life2 shuts down, does all of the memory allocations that were > >>> created during the game get deallocated automatically, so other programs > >>> can > >>> use them? > >>> > >>> > >>> ----- Original Message ----- > >>> From: "Jamie Femia" <[EMAIL PROTECTED]> > >>> To: <[email protected]> > >>> Sent: Friday, January 11, 2008 9:55 AM > >>> Subject: Re: [hlcoders] CUtlVector<*>... Memory management? > >>> > >>> > >>> > >>>> -- > >>>> [ Picked text/plain from multipart/alternative ] > >>>> Then why is it that when I try and delete the elements it crashes the > >>>> game? > >>>> lol... > >>>> > >>>> On Jan 11, 2008 5:37 PM, Tony omega Sergi <[EMAIL PROTECTED]> wrote: > >>>> > >>>> > >>>>> -- > >>>>> [ Picked text/plain from multipart/alternative ] > >>>>> you have to delete what you add. purging just removes the elements. > >>>>> > >>>>> On Jan 11, 2008 11:35 AM, Jamie Femia <[EMAIL PROTECTED]> wrote: > >>>>> > >>>>> > >>>>>> -- > >>>>>> [ 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 > >>>>>> > >>>>>> > >>>>>> > >>>>> -- > >>>>> -omega > >>>>> -- > >>>>> > >>>>> _______________________________________________ > >>>>> 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
