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

The answer really depends on how large your program will be and what performance characteristics it needs to exhibit. If you never deallocate memory, your process's memory footprint will be much larger than it would otherwise be. Depeding on the system, this could cause a lot of paging and slow down the performance for you or other applications on the system.

Beyond that, what everyone above says is correct. It probably won't cause harm in the short term, but it's a bad practice that you should avoid. You'll never be able to use the code again. Trying to retrofit a GC on afterwards will be a nightmare. Just think about going to each place you allocate memory and trying to retrofit it but not break anything.

One more reason to avoid doing this: reputation. If you fail to deallocate, everyone who maintains the code will curse your name and your rep in the company will take a hit. "Can you believe how dumb he was? Look at this code."

Answer 2

Not deallocating memory should not be problem but it is a bad practice.

Answer 3

Reference counting smart pointers like shared_ptr in boost and TR1 could also help you manage your memory in a simple manner.

The drawback is that you have to wrap every pointers that use these objects.

Answer 4

Try to use automatic variables in methods so that they will be freed automatically from the stack.

The only useful reason to not free heap memory is to save a tiny amount of computational power used in the free() method. You might loose any advantage if page faults become an issue due to large virtual memory needs with small physical memory resources. Some factors to consider are:

If you are allocating a few huge chunks of memory or many small chunks.

Is the memory going to need to be locked into physical memory.

Are you absolutely positive the code and memory needed will fit into 2GB, for a Win32 system, including memory holes and padding.

Answer 5

It shouldn't cause any problems in the specific situation described the question.

However, it's not exactly normal. Static analysis tools will complain about it. Most importantly, it builds bad habits.

Answer 6

I have not personally used this, but since you are starting from scratch you may wish to consider the Boehm-Demers-Weiser conservative garbage collector