Is it acceptable not to deallocate memory

Question

I'm working on a project that is supposed to be used from the command line with the following syntax:

program-name input-file

The program is supposed to process the input, compute some stuff and spit out results on stdout.

My language of choice is C++ for several reasons I'm not willing to debate. The computation phase will be highly symbolic (think compiler) and will use pretty complex dynamically allocated data structures. In particular, it's not amenable to RAII style programming.

I'm wondering if it is acceptable to forget about freeing memory, given that I expect the entire computation to consume less than the available memory and that the OS is free to reclaim all the memory in one step after the program finishes (assume program terminates in seconds). What are your feeling about this?

As a backup plan, if ever my project will require to run as a server or interactively, I figured that I can always refit a garbage collector into the source code. Does anyone have experience using garbage collectors for C++? Do they work well?

Answer 1

Sometimes not deallocating memory is the right thing to do.

I used to write compilers. After building the parse tree and traversing it to write the intermediate code, we would simply just exit. Deallocating the tree would have

• added a bit of slowness to the compiler, which we wanted of course to be as fast as possible.
• taken up code space
• taken time to code and test the deallocators
• violated the "no code executes better than 'no code'" dictum.

HTH! FWIW, this was "back in the day" when memory was non-virtual and minimal, the boxes were much slower, and the first two were non-trivial considerations.

Answer 2

I've done this before, only to find that, much later, I needed the program to be able to process several inputs without separate commands, or that the guts of the program were so useful that they needed to be turned into a library routine that could be called many times from within another program that was not expected to terminate. It was much harder to go back later and re-engineer the program than it would have been to make it leak-less from the start.

So, while it's technically safe as you've described the requirements, I advise against the practice since it's likely that your requirements may someday change.

Answer 3

What are your feeling about this?

Some O/Ses might not reclaim the memory, but I guess you're not intenting to run on those O/Ses.

As a backup plan, if ever my project will require to run as a server or interactively, I figured that I can always refit a garbage collector into the source code.

Instead, I figure you can spawn a child process to do the dirty work, grab the output from the child process, let the child process die as soon as possible after that and then expect the O/S to do the garbage collection.

Answer 4

When you exit from a program, the memory allocated is automatically returned to the system. So you may not deallocate the memory you had allocated.

But deallocations becomes necessary when you go for bigger programs such as an OS or Embedded systems where the program is meant to run forever & hence a small memory leak can be malicious.

Hence it is always recommended to deallocate the memory you have allocated.

Answer 5

My feeling would be something like "WTF!!!"

Look at it this way:

• You choose a programming language that does not include a garbage collector, we are not allowed to ask why.

• You are basically stating that you are too lazy to care about freeing the memory.

Well, WTF again. Laziness isn't a good reason for anything, the least of what is playing around with memory without freeing it.

Just free the memory, it's a bad practice, the scenario may change and then can be a million reasons you can need that memory freed and the only reason for not doing it is laziness, don't get bad habits, and get used to do things right, that way you'll tend to do them right in the future!!

Answer 6

If the run time of your program is very short, it should not be a problem. However, being too lazy to free what you allocate and losing track of what you allocate are two entirely different things. If you have simply lost track, its time to ask yourself if you actually know what your code is doing to a computer.

If you are just in a hurry or lazy and the life of your program is small in relation to what it actually allocates (i.e. allocating 10 MB per second is not small if running for 30 seconds) .. then you should be OK.

The only 'noble' argument regarding freeing allocated memory sets in when a program exits .. should one free everything to keep valgrind from complaining about leaks, or just let the OS do it? That entirely depends on the OS and if your code might become a library and not a short running executable.

Leaks during run time are generally bad, unless you know your program will run in a short amount of time and not cause other programs far more important than your's as far as the OS is concerned to skid to dirty paging.