The murderous Memory Man is officially called STATUS_NO_MEMORY (cf.
ntstatus.h), but other than that, I guess Counter-Strike taught you a
lot about the internals of Windows. ;-)
When a process is terminated, the Windows kernel, at least since NT
3.51, frees any and all memory belonging to the process. (Unix does that
too.) However, this is often too late -- depending on how long the game
runs.
Suppose I load a map. My ultra-awesome constructor for some sort of
in-game class creates a pointer to an overly large class for optimized
resource management. During the course of this map, these special
resources get loaded by this resource manager, taking up memory.
Now, suppose I change maps. My stupid destructor for that in-game class
forgets to free the resource manager, which, in turn, doesn't free all
the resources (because it was never told to do so). If my special
resources are something akin to id's MegaTextures, the application will
eventually -- third map the latest -- run out of memory and the Memory
Man will ring my doorbell and try to rape me with a crowbar.
There is a big philosophical difference between the heap and the stack:
when a stack variable goes out of scope, it is destroyed (and the memory
it occupied is freed), whilst a heap variable never goes out of scope.
This is pretty sweet for global objects, externally serialized objects
and the victims of pointer arithmetic fetishists, but it is always
considered good practice to, when the item is not needed anymore, bolt
the variable -- new'd variables with delete, malloc'd variables with free.
If I do this right, I never waste memory. In practice, with all the
pointer passing in a game engine, it is much more troublesome, but
anytime memory can be freed, it should be freed.
... unless you want the server admins to do what the Memory Man is said
to do. That's a group of people aiming for lots of uptime.
(D'oh! In the mean time, Jed has given a shorter description of memory
handling and Yahn chimed in to inform everybody of the engine's
behavior. I guess I'll send this anyway as a dire warning.)
~~ Ondra
P.S. In case you're wondering, yes, this post is 99% hyperbole. Oh,
there it is again.
On 11.01.08 20:08 Uhr, Minh wrote:
--
[ Picked text/plain from multipart/alternative ]
What happens if you don't properly release the memory? Will the Memory Man
come to your house and beat you to death?
If the app is running under Windows and windows knows how much memory is
being allocated, then couldn't we just rely on windows to take care of the
memory deallocation process? Or perhaps, we don't trust Windows....
----- Original Message -----
From: "Jed" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, January 11, 2008 10:58 AM
Subject: Re: [hlcoders] CUtlVector<*>... Memory management?
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
