Jump to content
  • Advertisement
Sign in to follow this  
L. Spiro

Do You Release Resources at Program Termination?

This topic is 2630 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

Advertisement
In debug yes. Without doing so it isn't easy to check for memory or resource leaks.
In release though, for some large apps all the important things are destroyed and then the app is simply terminated. Small apps where the time difference is negligible, everything is just cleaned up naturally.

That's about the best of both worlds IMHO.

Share this post


Link to post
Share on other sites
Always.

My rationale is simple: termination is just another valid program state. A program should be able to transition through all valid states (including termination!) without leaking resources. If my app can exit and clean up from itself correctly, I have a stronger chance (but not a guarantee!) that I can run it for long periods of time without exhausting resources.

Of course, I also work on extremely high-uptime server software, so that might have colored my biases a bit :-)

Share this post


Link to post
Share on other sites
I clean everything to catch leaks. However, I have to admit that sometimes I cut some corners on cleaning... hopefully those will go away in the future.

Share this post


Link to post
Share on other sites

Always.

My rationale is simple: termination is just another valid program state. A program should be able to transition through all valid states (including termination!) without leaking resources. If my app can exit and clean up from itself correctly, I have a stronger chance (but not a guarantee!) that I can run it for long periods of time without exhausting resources.

My engine is the virtual embodiment of this philosophy.
I group all parts into modular states. The main menu, options menu, bonus rounds, gameplay scene, etc., are all separate classes that inherit from the state base class. Being entirely modular, states can be run in any order (with rare exceptions).

The engine provides 2 built-in states: Default and Invalid. The engine terminates by going into the Invalid state.

Because no state can assume that it will always be followed by the invalid state, all states are required to release all memory they use. Since this is enforced, it also allows me mid-game leak detection. Special cases barred, the memory layout should be exactly the same before the state started and after it ends. Any allocations not released are printed to the debug console as leaks.


This organization implicitly recognizes termination as another state, and causes full memory release to happen before shutting down.


L. Spiro

Share this post


Link to post
Share on other sites
I don't see the point in deliberately skipping proper destruction during termination, unless maybe if you're using a lot of C++ objects with destructors that call destructors that call destructors, etc, to the point where destruction actually starts taking many seconds to complete.

IMO game-engine level C++ should be a lot more deliberate/planned in it's allocations than the above case though, with most objects being POD, and only objects that truly have a requirement to track resource ownership having proper destructors. Also, the resource of RAM shouldn't always be managed by the "general purpose" solution, when simpler alternatives are suitable.
e.g. below, each of the [font="Courier New"]new[/font]ed objects would still have a destructor called (to release resources other than RAM), but all of their RAM allocations are released with a single call to [font="Courier New"]free[/font].void* memory = malloc(MiB(64));
{
StackScope a(memory, MiB(64));
Engine* engine = new(a) Engine(a);
Loading* loadingScreen = new(a) Loading(a);
MainMenuState* mainMenu = new(a) MainMenu(a);
u32 gameUnwindPoint = a.Mark();
bool quit;
do{
GameState* game = mainMenu->Run(a, loadingScreen);
quit = game->Run(a, loadingScreen);
a.Unwind(gameUnwindPoint);
}while(!quit);
}
free(memory);

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!