3

This might be a bit stupid question - should I call delete on huge map/set at the end of the program?
Assuming the map/set is needed throughout all program (delete is last line before return) and it's size is really huge (> 4GB). The delete call take a long time and from my perspective does not have any value(memory cannot be released any sooner), am I wrong? If so, why?

wondra
  • 3,271
  • 3
  • 29
  • 48
  • 3
    IMHO always `delete` what you `new`. Just because something is at the end of the program now doesn't mean it always will be. And the person that adds code afterwards is now leaking memory and doesn't realize it. – Cory Kramer Sep 28 '14 at 19:04
  • @Cyber Can you format your comment into answer? Best with arguments/resources to give it best value. thanks – wondra Sep 28 '14 at 19:07
  • Possible duplicate: http://stackoverflow.com/questions/677812/is-there-a-reason-to-call-delete-in-c-when-a-program-is-exiting-anyway – Csq Sep 28 '14 at 19:08
  • 1
    [And if the process is exiting, then you should just return without doing anything. No, really.](http://blogs.msdn.com/b/oldnewthing/archive/2012/01/05/10253268.aspx) – GSerg Sep 28 '14 at 19:08
  • What I know for sure is that pointers and dynamic memory allocation should be freed by you. In other words, every malloc should be freed after its use. – George Eco Sep 28 '14 at 19:14
  • @GSerg not really a duplicate - that was a general question, not special case of big data and slow deallocation – wondra Sep 28 '14 at 19:45
  • You could add a method to free the memory and add an argument to the constructor to tell the tree whether to auto-delete or only delete if the method is called. This would make it explicit to anyone who comes along later to not assume that it auto-deletes while still allowing you to not free memory for no reason at the end if the process. – Tyler Sep 28 '14 at 19:52
  • One aspect could also be that "unintentional" memory leaks can be obsured by "intentional" when running tools like valgrind. – user2672165 Sep 28 '14 at 20:13

3 Answers3

7

There is no guarantee in the C and C++ standards of what happens after your program exits. Including no guarantee that anything is cleaned up. Some smaller real-time OS' for example, will not perform automatic cleanup. So at least in theory, your program should definitely do delete everything you new to fulfil it's obligation as a complete and portable program that can run forever.

It is also possible that someone takes your code and puts a loop around it, so that your tree is now created a million times, and then goes to find you, bringing along the "trusty convincer", aka base-ball bat, when they find out WHY it's now running out of memory after 500 iterations.

Of course, like all things, this can be argued many different ways, and it really depends on what you are trying to achieve, why you are writing the program etc. My compiler project leaks memory like a sieve, because I use exactly the method of memory management that you describe (partly because tracking the lifetime of each dynamically allocated object is quite difficult, and partly because "I can't be bothered". I'm sure if someone actually wants a good pascal compiler, they won't go for my code anwyay).

Actually, my compiler project builds many different data structures, some of which are trees, arrays, etc, but basically none of them perform any cleanup afterwords. It's not as simple to fix as the case of building a large tree that need each node deleting. However, conceptually, it all boils down to "do cleanup" or "not do cleanup", and that in turn comes down to "well, who is going to use/modify the code, and what do you know about the environment it will run in".

Mats Petersson
  • 126,704
  • 14
  • 140
  • 227
1

As long as your program stays more or less the same, with the memory being used for the entire execution, it doesn't make a real difference.

However, if someone ever tries to take your program and make it into a component of some other program, not releasing the memory could result in a huge memory leak.

So to be on the safe side, and also to be more organized, always free what you allocate. In your case it's very easy so there's no downside - just a potential upside.

zmbq
  • 38,013
  • 14
  • 101
  • 171
1

If you are using C++ STL, then there is no need for any explicit deletion, because map/set will automatically manage heap memory for you. Actually, you are not allowed to delete those map/set, since they are not pointers.

For the large objects stored inside map/set, you can use smart pointers when constructing those objects, and then you will no longer need to call their destructors. Memory leak may not be a problem for a toy program, but it is unacceptable for real-life programs, since they may run for a long time or even forever.

wayi
  • 513
  • 1
  • 6
  • 14