Jump to content
  • Advertisement
Sign in to follow this  
NightCabbage

Cleanup After C++

This topic is 3888 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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)

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
"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?

Share this post


Link to post
Share on other sites
Quote:
Original post by NightCabbage
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?
That 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).

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?

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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?)

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!