50

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.

rbento
  • 5,069
  • 1
  • 40
  • 51
Nick Bolton
  • 34,516
  • 66
  • 162
  • 230
  • 1
    The duplicate mentioned is about C, which misses out on some important information about the destructor which is a problem in C++. – Brian R. Bondy Mar 24 '09 at 15:12
  • @Brian, my answer to the duplicate also mentions destructors (now). My feeling that this one should be deleted still stands. – Paul Tomblin Mar 24 '09 at 15:14
  • Not sure what you mean about destructor - please clarify. – Nick Bolton Mar 24 '09 at 15:15
  • Basically the question has a different answer for C and C++. In C++ you have to also consider that there is an even greater reason to delete your memory in your program because if you don't your destructor of your class won't be called. Which may contain very important code. – Brian R. Bondy Mar 24 '09 at 15:17
  • Ah, good point. I think my question also makes the point of "should I delete anyway, out of good practice?" - not just "should I delete when exiting?". – Nick Bolton Mar 24 '09 at 15:20
  • @Paul Tomblin: But the question over there is only tagged with, and only asks about C. So your answer I guess would be more suited here. If the other question asked about C/C++ then I would say your answer should be accepted over there though. – Brian R. Bondy Mar 24 '09 at 15:20
  • Ok, you've convinced me. But I still like my answer to that other question best. – Paul Tomblin Mar 24 '09 at 15:39

8 Answers8

79

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.

Brian R. Bondy
  • 314,085
  • 114
  • 576
  • 619
  • 12
    Don't forget that a class member may also hold something that doesn't automatically disappear with the end of the program, such as a socket or connection or something. Memory isn't the only thing that leaks, and not all leaks can be automatically cleaned up. – David Thornley Mar 24 '09 at 15:42
  • 1
    What if i have allocated memory for Tree (specifically trie), and inside destructor, all i need to do is `delete`. Do i still need to explicitly call delete? or rely on OS to do for me? – Vinayak Garg May 04 '12 at 06:09
27

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

Ferruccio
  • 93,779
  • 37
  • 217
  • 294
12

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.
Lightness Races in Orbit
  • 358,771
  • 68
  • 593
  • 989
  • 2
    Point #3 is the most compelling for me. It's less effort to just always delete your allocations than to try and always decide when it's appropriate. Reminds me of using car turn signals - I always wondered why people bothered to use it *sometimes*; it's better to make it a habit where you don't have to think of it at all. – tenfour Dec 19 '11 at 10:28
  • @tenfour: Indeed. If you can't guarantee that the car in front of you always indicates when appropriate, then you can't _ever_ be sure when he's not turning. The whole system breaks down. – Lightness Races in Orbit Dec 19 '11 at 10:38
  • @LightnessRacesinOrbit: +1 for saying that "The standard doesn't guarantee that the OS will clean up the memory. ". I also like your 3rd point. – Destructor Nov 28 '15 at 13:51
8

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.

Unihedron
  • 10,251
  • 13
  • 53
  • 66
Stefan
  • 42,026
  • 10
  • 73
  • 116
7

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.

Sebastian Mach
  • 36,158
  • 4
  • 87
  • 126
4

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.

Mr Fooz
  • 95,588
  • 5
  • 65
  • 95
4

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.

Unihedron
  • 10,251
  • 13
  • 53
  • 66
Nemanja Trifunovic
  • 23,597
  • 3
  • 46
  • 84
3

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

RvdK
  • 18,577
  • 3
  • 56
  • 100