CODEWITHSUNDEEP
memory-managementlanguage-agnosticresources
johnfound
johnfound

Reputation: 7061

Is there some rational reason to free allocated resources in short living programs?

There is a class of short living programs that are working this way:

1. Allocate some resources - memory, open files, etc.
2. Make some computations
3. Free allocated resources
4. Terminate

The same question is valid for the termination stages of long lived programs of the type:

1. Do some job
2. If not the end - goto 1
3. Free the resources still allocated
4. Terminate

Now, we know that the OS itself always cleans after the program termination. Is it really necessary to clean the allocated memory by our code, if it will be, with the same success, freed by the OS, one step further?

Can we safely omit the point 3 in the above examples? It is time and code after all.

Clarification 1: I am not talking about libraries where the code can be reused by someone in different context. I am asking about the finished programs, where the above structure is clean enough.

Clarification 2: The "good practices" are called so, because they are intended to prevent "bad effects". But if the bad effect is impossible to happen, are these practices still "good"? Or it is simply "tradition"?

Upvotes: 0

Views: 98

Answers (4)

Jerry Coffin
Jerry Coffin

Reputation: 490228

I don't think there's really a meaningful language-agnostic answer to this.

In languages that use a garbage collector, it's unlikely that the GC would run automatically before exit, and it would generally be quite pointless to manually force it to run (even if we assume you're using a language/library that allows you to do so).

In C++, resource acquisition should almost always happen in a constructor, and freeing that resource should normally happen in the matching destructor. In this case, writing the code without the proper destructor is almost certainly a bug -- you're simply writing a class that's incomplete and hoping that it'll only ever be used in a way that keeps that bug from manifesting itself.

In C, or anything else similar where you have to do the cleanup manually, I prefer to write the code to do that final cleanup, but normally comment it out. This can improve both speed and code size, as well as ensuring against any bugs in the code for freeing the data (pretty hard for code that isn't compiled to cause a problem).

Upvotes: 1

Sergey L.
Sergey L.

Reputation: 22542

I have asked myself that question at some point too and after a small debate I came to the conclusion:

It is good practice to free resources in case you do decide to reuse that code in a larger project later. There is nothing worse then debugging old code. Do it right straight away and stick to good programming practices.

Upvotes: 0

Mats Petersson
Mats Petersson

Reputation: 129374

This depends very much on the OS. Most modern OS's will automatically free all resources when a program terminates, which maans that there is no actual requirement to free things before exiting the program.

But this is not always the case, in particular certain types of embedded OS's will have a simpler approach.

Of course, it also doesn't work very well when you (or more importantly, someone else) decide to take your code and turn it from a short running process to a long lived program...

Upvotes: 2

No One in Particular
No One in Particular

Reputation: 2894

You should ALWAYS clean up after yourself. You can never tell when someone will take your code and use it in a different situation.

Coding up a complete solution is the correct thing to do in all circumstances.

Upvotes: 0

Related Questions