Is there a reason to call delete in C++ when a program is exiting anyway?

Question

In my C++ main function, for example, if I had a pointer to a variable which uses heap memory (as opposed to stack memory) - is this automatically deallocated after my application exits? I would assume so.

Even so, is it good practice to always delete heap allocations even if you think they will never be used in a situation where the memory is automatically deallocated on exit?

For example, is there any point in doing this?

int main(...)
{
    A a = new A();
    a->DoSomething();
    delete a;
    return 0;
}

I was thinking maybe in case I refactor (or someone else refactors) that code and puts it elsewhere in the application, where delete is really neccecary.

Edit:

As well as the answer by Brian R. Bondy (which talks specifically about the implications in C++), Paul Tomblin also has a good answer to a C specific question, which also talks about the C++ destructor.

Answer 1

This is a near duplicate if not a duplicate of http://stackoverflow.com/questions/654754/what-really-happens-when-you-dont-free-after-malloc

Answer 2

It is important to explicitly call delete because you may have some code in the destructor that you want to execute. Like maybe writing some data to a log file. If you let the OS free your memory for you, your code in your destructor will not be executed.

Most operating systems will deallocate the memory when your program ends. But it is good practice to deallocate it yourself and like I said above the OS won't call your destructor.

As for calling delete in general, yes you always want to call delete, or else you will have a memory leak in your program, which will lead to new allocations failing.

Answer 3

Think about your class 'A' having to deconstruct. If you don't call 'delete' on 'a', that destructor won't get called. Usually, that won't really matter if the process ends anyway. But what if the destructor has to release e.g. objects in a database? Flush a cache to a logfile? Write a memory cache back to disk?

You see, it's not just 'good practice' to delete objects, in some situations it is required.

Answer 4

Consider the case where the object to be deleted acquired an external resource which can't be freed safely by the OS. If you don't call delete on that object, you have a real leak.

Answer 5

always make sure you delete it yourself. An OS will take care of this but to exclude bugs that can easily be avoided

Answer 6

Yes, it helps to eliminate false positives when you run your program through a memory leak detection tool.

Answer 7

Another reason for explicitly deleting objects is that if your application has a real memory leak, it becomes easier to use tools like valgrind to find the leaks if you don't have to sift through "leaks" that come from not bothering to clean up.

Answer 8

Another reason to delete is to avoid false alarms from a leak detector you may use in future. If you have false alarms you may not pay attention to a real leak reported by a leak detector - it will be burried among the false ones in the report.

[EDIT] There is an almost identical answer that appeared while I was writing this :)[/EDIT]