2

After reading this answer about what is memory leak one can conclude that if object is supposed to exist during all run of program, and was creating via new, there is no need to call delete on such object.

So, for example, if I have some main window, and some other windows/widgets on it, that I create in main window constructor with new, I don't need to call delete in destructor, as main window destructor will be called on program quit, so it isn't a memory leak.

Community
  • 1
  • 1
GraphicsToBe
  • 115
  • 4

4 Answers4

3

Until your program becomes a module in a larger program, e.g. a servlet, at which point you now have a leak.

Also it will obscure your code reviews and use of valgrind. valgrind will think it's a leak, why would you want to have to remember that "that one is fine" each time you try to track down a leak elsewhere?

djechlin
  • 59,258
  • 35
  • 162
  • 290
3

'cos main window destructor will be called on program quit, so it isn't a memory leak

It is a memory leak, but you can rely on the fact that the operating system will release the resources (at least the memory) used by your process when the process terminates - even if the process itself does not take actions to actively do this.

That may not be the case, though, when other kinds of resources need to be released, like file handles or network connections. More generally, when other kinds of responsibility are not fulfilled by a program or module that has those responsibilities.

Not leaking memory is a responsibility of your program, and it is good to practice programming in a way that the modules you write will fulfill their responsibilities. The tools and idioms used for this purpose are general enough to justify practicing their usage whenever this makes sense. For instance, the RAII idiom (Resource Acquisition Is Initialization) is fundamental in this respect, and it can be applied to your example as well - use a smart pointer.

Although in the particular example you are mentioning your memory leak is not going to be a huge problem (memory consumption won't keep growing as your program is running, because we're talking about one object), there is no real reason for keeping it there.

Andy Prowl
  • 124,023
  • 23
  • 387
  • 451
  • How can it be a leak if it is still accessible up to the point where the process ceases to exist? – Martin James Apr 06 '13 at 22:18
  • @MartinJames: If your process does not release the memory it allocated before its execution terminates, it is a leak by definition. The OS keeps track of all the memory allocated by your process and releases it after its termination (if some hasn't been released yet). However, it's not your process that does that actively. – Andy Prowl Apr 06 '13 at 22:20
  • To me, a leak is allocated memory for which access has been lost because of.. whatever during the app run, and is an error/bug. Intentionally not deleting app-lifetime objects/whatever is not. – Martin James Apr 06 '13 at 22:24
  • @MartinJames: If the memory is allocated, and access is lost *by the program* (not by the OS), [then you have a leak](http://en.wikipedia.org/wiki/Memory_leak). The OS always has access to memory allocated by processes, because it keeps a map of every block it allocates upon requests made by processes - and after a process termination, it releases the memory that those processes forgot to release (i.e. leaked). – Andy Prowl Apr 06 '13 at 22:31
  • If the memory is allocated, and access is lost by the program (not by the OS), then you have a leak - indeed, yes. I am highlighting the cases where an object release has not been 'forgotten', but has been intentionally not performed explicitly by the process shutdown code. A developer may well inentionally avoid explicit deletion because it is unsafe to do so until all process threads have been stopped - something that can be extremely difficult for user code to implement, but trivial for the OS. – Martin James Apr 06 '13 at 22:38
  • @MartinJames: In that case you still have a leak, it's just an intentional leak. Not all leaks are dangerous: a programmer may rely on documented behavior of the OS, but that doesn't make a leak become a non-leak just because a programmer is aware of it. On an OS that does not free unreleased memory automatically, that leak would be a more serious issue. – Andy Prowl Apr 06 '13 at 22:42
  • 1
    Well, whether we call it a leak or not, we seem to agree anyway :) – Martin James Apr 06 '13 at 22:43
2

When you start a program, a process will be created by the OS containing all of the information needed to run the program.
When the process is destroyed, for example by closing the main window, the OS will clean up (not immediately) the image of the process from Memory and your Memory leaks will disappear.
pIt becomes a Problem if you have a long running process and create memory leaks, so the process will either die or the OS starts to run slow.

bash.d
  • 13,029
  • 3
  • 29
  • 42
2

It is better to get into the habit of deleteing memory yourself (or use smart pointers), because code changes over time, and who knows if the object will last the lifetime of the program in the future, when you (or the next developer) have long since forgotten that you didn't have a matching delete for your new.

JBentley
  • 6,099
  • 5
  • 37
  • 72