Why free resources if the program is already quitting?

Question

Memory and resources are not the same thing.

Memory is released automatically.

Resources may, or may not, be released automatically.

Even if your OS (not all do that) frees memory at exit, there are some reasons:

• it's good manner
• it adds symmetry, so code looks better
• OS does not automatically free some resources at exit, like devices (sensors, scanners...)
• if someone takes this code and places it in a program that uses the libraries only in a small part of his runtime, the resources will be free when not needed.
• if you are looking for bad memory leaks, your debugger won't find these unimportant ones.

Whether the resources allocated to a program will be reclaimed or not depends on the Operating systems. Note that specifically some embedded systems do not free the resources.

Most operating systems do reclaim and free the resources allotted but it is bad practice to rely on the behavior of the OS for this and hence you should free all the acquired resources before you quit your program.

In general I agree what others have said: if you don't practice good habits in the little things, you'll fail with the big ones as well. However your question rang (an old) bell, about crash-only software.

While that concept extends "a little" further than your original question (it not only deals with OS resources, but with your own (open files, etc.), you might still be interested in it.

The basic idea is, if software should not destroy user data, etc. in the face of a crash (think of databases / tx logs, etc.) why should you even design/program a clean exit path. If you need to restart, rerun it, you might as well "let it crash".

Well, I guess one can argue about the virtues of that all day, but it is interesting nevertheless.

It is a good idea to tidy up after yourself.

For one - freeing up resources will tidy up file descriptors/network connections/shared memory etc. in a controlled manner.

Secondly, if you are using something like purity you can ensure that all the memory is taken into account of - thus giving a better sense that no memory leaks are occurring.

I suppose the first thing that should be mentioned is that not all resources are the same.

None of these structures (in most OSes) are automatically cleaned up at application close:

• Shared memory pools
• Named Win32 Mutex/Semaphore/Event/etc. objects
• Certain kinds of socket connections
• Proprietary hardware device driver data structures (obscure)

... and I'm sure I'm forgetting some.

In the small, it might be easy to know whether your application uses any of these types of objects and control for it. However, in larger applications it isn't hard to get to a point where you have some deeply-embedded (3rd party?) subsystem that does allocate one or more of these special structures and if the rest of your application leaks like a sieve, you might be in trouble.

It is really a matter of engineering discipline that says your application should clean up after itself on exit. You may not need it now but you might appreciate it later as your application gets larger.

One reason I see is:

Assume that you have the memory leaks dumped in the output window of your development environment on application exit. If you do not "clean-up" in a proper way you will have problems detecting the true leaks from all the leaks that come from "not bothering with it"