Why free memory on application quit?

Member
Posts: 749
Joined: 2003.01
Post: #1
Is there any practical reason why one should free allocated memory on quit? Isn't it taken care by the OS?

©h€ck øut µy stuƒƒ åt ragdollsoft.com
New game in development Rubber Ninjas - Mac Games Downloads
Quote this message in a reply
Moderator
Posts: 608
Joined: 2002.04
Post: #2
For the warm fuzzy feelings of cleanliness?
Quote this message in a reply
Member
Posts: 72
Joined: 2006.10
Post: #3
It's mostly a question of good practice. You allocate, you free. In some cases, this can save you a bunch of headaches if you ever want to change a number of global constructs to ephemeral ones.

The other main use is memory leak tracking. If your application is supposed to delete everything before quitting, then anything remaining right before quitting is necessarily a leak, QED. With full memory freeing, there is no possible confusion between a leak and global memory.

- Sohta
Quote this message in a reply
Member
Posts: 749
Joined: 2003.01
Post: #4
sohta Wrote:It's mostly a question of good practice. You allocate, you free. In some cases, this can save you a bunch of headaches if you ever want to change a number of global constructs to ephemeral ones.

The other main use is memory leak tracking. If your application is supposed to delete everything before quitting, then anything remaining right before quitting is necessarily a leak, QED. With full memory freeing, there is no possible confusion between a leak and global memory.

Hm, those are fairly convincing Wink

Practically how would you check the memory left right before quitting the app?

©h€ck øut µy stuƒƒ åt ragdollsoft.com
New game in development Rubber Ninjas - Mac Games Downloads
Quote this message in a reply
Member
Posts: 72
Joined: 2006.10
Post: #5
Najdorf Wrote:Hm, those are fairly convincing Wink

Practically how would you check the memory left right before quitting the app?

There is a number of different ways of doing it.

In Object-oriented programming, you can have a static variable that gets incremented in constructors and decremented in destructors.

In C++, simply overwrite new and delete to maintain an allocation table.

In C, do the same thing by piping your malloc/free calls through your own functions.

Some places I've worked at have amazingly complex memory management systems with the sole purpose of attaching chuncks of metadata to allocations in order to track them, and maintain a lightweight linked-list of curently allocated stuff in order to be able to do a memory dump at any time.

Edit: morning, not enough cofee in blood yet...

- Sohta
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #6
You shouldn't. Just get out as quickly as you can for the user's sake and let the OS tidy up after you.

Leak-detection tools (leaks, valgrind) don't care.

C++ static destructors are particularly evil.
Quote this message in a reply
Member
Posts: 72
Joined: 2006.10
Post: #7
I will respectfully disagree with OSC on this one. If destruction takes any time whatsoever for you, then you have other issues on your hands.

Also, I am not sure what you mean by static destructor. If you refer to destructors being called on static variables, then yes. However, I will add that anything doing dynamic allocations before the start of main() is quite evil as well.

- Sohta
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #8
What's a C++ static destructor?
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #9
There is no benefit to freeing the memory at quit, so why would you? It's always better for the user that you not.

Yes, I mean destructors on static variables. And yes, static constructors are at least as evil Wink
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #10
OneSadCookie Wrote:Yes, I mean destructors on static variables. And yes, static constructors are at least as evil Wink

OK, I understand now. That's something I've avoided like the plague for years; it's something so alien and wrong to me that I didn't even recognize what you meant. Rasp
Quote this message in a reply
Moderator
Posts: 3,571
Joined: 2003.06
Post: #11
I'm with the "let the OS do it on quit" crowd. I don't see much point in writing code that doesn't do anything other than being "tidy".
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #12
Don't forget "slow" (yes, really, whatever sohta says) and "error-prone" Rasp
Quote this message in a reply
Member
Posts: 72
Joined: 2006.10
Post: #13
I dunno, I used to have this mentality as well until I got burned pretty bad by it. Mind you, there is no reason to not have your cake and eat it too. The fact that your program cleans itself up properly in no way prevents you to call exit(0) in the version that ships to the consumer.

- Sohta
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #14
Please explain how you got burned?
Quote this message in a reply
⌘-R in Chief
Posts: 1,247
Joined: 2002.05
Post: #15
sohta: Did you know that that every Mac OS X Cocoa application out there does not free all of its memory before it quits? After a certain point in the termination process is reached, the whole process just exits rather than release every single object first.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  My game crashes on quit... hangt5 17 8,240 Jan 30, 2005 09:38 PM
Last Post: hangt5
  Carbon Apple quit Event troubles deekpyro 3 5,740 May 7, 2002 06:24 AM
Last Post: deekpyro