Cleanup After C++
Author
Hello
Just a quick question...
Why is it that I keep reading how important it is to release objects, etc. before your game exits?
Surely when the game exits ALL memory would be cleared?
ie. that is handled by Windows
I can understand why you'd want to clean up during the runtime of the game, so you don't get a memory leak and slowdown... but why, if you're going to quit anyway, do you need to release stuff?
The only thing I can think of is that maybe when you release a texture, for example, it tells the video card to unload that texture, etc.
Is that it? For the video card?
(obviously I'm used to working with languages with garbage collection like Java and C# lol)
If your game exits and the OS that runs your game releases all memory and handles (which a proper OS should), then you shouldn't worry about releasing all these things by yourself.
On most consoles your game would never exit anyway (without some sort of reset), so you don't have to worry about it at all.
However it is good practice to release everything manually [in Debug builds]. Often just to check whether you have a leak somewhere in your code.
On most consoles your game would never exit anyway (without some sort of reset), so you don't have to worry about it at all.
However it is good practice to release everything manually [in Debug builds]. Often just to check whether you have a leak somewhere in your code.
In C++ when an object is deleted, its destructor is called. If you simply exit the program suddenly, then the memory will be freed (by the OS), but the destuctors will not be called.
In a simple program, the destructors may just be cleaning up memory, in which case it would be safe to simply call exit and let the OS clean up your mess.
But in a more advanced program, often the destructor will have important tasks to complete, such as releasing graphics handles, closing files, writing info to a data-base, terminating a sound loop, etc, etc...
If a program uses the RAII idiom (which many will argue is a very good practice in C++ programming), then respecting the destructor is imperative!
In a simple program, the destructors may just be cleaning up memory, in which case it would be safe to simply call exit and let the OS clean up your mess.
But in a more advanced program, often the destructor will have important tasks to complete, such as releasing graphics handles, closing files, writing info to a data-base, terminating a sound loop, etc, etc...
If a program uses the RAII idiom (which many will argue is a very good practice in C++ programming), then respecting the destructor is imperative!
Author
"such as releasing graphics handles, closing files, writing info to a data-base, terminating a sound loop"
Ah, ok - so graphics handles... I've seen some games that, when exited incorrectly, can prevent you from opening another DirectX program until you restart your computer.
Is this why?
Ah, ok - so graphics handles... I've seen some games that, when exited incorrectly, can prevent you from opening another DirectX program until you restart your computer.
Is this why?
Quote:Original post by NightCabbageThat would be an example of why (or at least I suppose it is - I don't actually know that that particular problem is caused by a failure to release or clean up resources).
Ah, ok - so graphics handles... I've seen some games that, when exited incorrectly, can prevent you from opening another DirectX program until you restart your computer.
Is this why?
In any case, if your C++ coding practices are halfway decent, everything will get cleaned up automatically no matter what, which begs the question...how exactly are you getting yourself into a position where it's possible to leave resources unclaimed when the application terminates? In other words, how are you managing your dynamic resources, and what sorts of resources are you tempted to not clean up?
Author
I'm more wondering how to figure out WHAT needs cleaning up after :)
eg. if I make a texture, do I need to clean it up?
How about a game object... like a player or some such
(they're just examples but you get the idea)
How do you know what needs cleaning up?
eg. if I make a texture, do I need to clean it up?
How about a game object... like a player or some such
(they're just examples but you get the idea)
How do you know what needs cleaning up?
You should clean up absolutely everything you allocate!
Why? Because then when you have a problematic memory leak it will be a piece of cake to spot it using various leak detection tools. If it's hidden amoungst 1000's of other leaks then you'll have a hard time finding it.
The best way is to not write code that can leak to begin with.
Why? Because then when you have a problematic memory leak it will be a piece of cake to spot it using various leak detection tools. If it's hidden amoungst 1000's of other leaks then you'll have a hard time finding it.
The best way is to not write code that can leak to begin with.
Author
Ok, I guess I just need to get my head around cleaning stuff up :)
So if I make anything, a string, an array, a texture, a struct, etc. I have to clean it up, right?
(by setting it to NULL? or calling the destructor? or just when it loses scope?)
So if I make anything, a string, an array, a texture, a struct, etc. I have to clean it up, right?
(by setting it to NULL? or calling the destructor? or just when it loses scope?)
Let's clear something up. Your program *should* clean up after itself and not leave it to the OS. But it doesn't have to. If it fails to clean up, the OS will correctly close all handles and release all the memory. Otherwise this would be a very serious bug in the OS as resources are leaked and lost forever until the system reboots.
The only reason you should clean up after yourself is good practice - don't get into the habit of leaving it and assuming something else will clean it up later. And, as iMalc said, it also assists in debugging.
When people say "clean up" they mean releasing all resources (such as a texture) and deleting all memory that you've allocated.
The only reason you should clean up after yourself is good practice - don't get into the habit of leaving it and assuming something else will clean it up later. And, as iMalc said, it also assists in debugging.
When people say "clean up" they mean releasing all resources (such as a texture) and deleting all memory that you've allocated.
Quote:Original post by NightCabbage
Ok, I guess I just need to get my head around cleaning stuff up :)
So if I make anything, a string, an array, a texture, a struct, etc. I have to clean it up, right?
(by setting it to NULL? or calling the destructor? or just when it loses scope?)
Anything new'ed should be delete'd (or, in case you're using C functions, the (almost) equivalent is malloc, realloc and free).
new automatically calls the constructor, and delete calls the destrutor - no need to do that yourself.
When you ask D3D or OGL to make room for a texture, or a third API to make room for any other data, you should also inform the proper API, if such a method exists within that API, when you don't need that room anymore.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
