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

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 necessary.

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.

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.

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

Yes.

• The standard doesn't guarantee that the OS will clean up the memory. You can expect this on the mainstream platforms, but why take the chance?
• You minimise clutter reported by tools like valgrind if you don't deliberately leak memory.
• If you get into this habit, who's to say that you won't one day accidentally apply this approach somewhere it matters?
• You may need object destruction. Usually just assume that you do. It doesn't hurt you.

Think about your class A having to destruct.
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.

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.

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

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 buried among the false ones in the report.

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