new() without delete() is Undefined Behavior or me

Question

Possible Duplicate:
Are memory leaks “undefined behavior” class problem in C++?

Never calling delete or delete[] on address returned by new or new [] resp in a C++ program is an Undefined Behavior or merely a memory leak?

References from the Standard(if any) are welcome.
This came up in one of the comments here & I am just a bit confused about it.

Answer 1

Let's say that if you do not call delete your program will still work. BUT if you do not delete memory allocations your program memory usage will keep growing until your program will run out of free memory (the longer you run it better are the chances for it to happen) which will cause crashes at different points and will be very hard to detect (and I think that whats 'Undefined Behavior' mentioned in the comment means)

Answer 2

The standard is clear with regards to the semantics of new and delete. There's certainly no undefined behavior if you don't call delete; it is, in fact, standard practice for singletons, and I imagine that std::cout and std::cin use new[] to acquire their buffers (which they almost certainly never delete). Why would not calling delete be undefined behavior?

What is undefined behavior is calling the wrong form of delete, calling free for memory allocated with new, or in general to attempt to delete an object without following the protocol required by its allocation.

Answer 3

It's just a memory leak.

But I explicitly remember the standard saying that use new with delete[] and new [] with delete is undefined behavior. (or any combination with malloc or free)

I don't think the standard specifically says calling new results in undefined behavior if you fail to call delete. Also, how can the run-time tell if you call delete sometime later or never call it at all?

I don't think there are any contracts in the standard that say - if you do X, you MUST do Y afterwards, otherwise it's UB.

Answer 4

[basic.life] (3.8 Object lifetime) in paragraph 4 tells :

A program may end the lifetime of any object by reusing the storage which the object occupies or by explicitly calling the destructor for an object of a class type with a non-trivial destructor. For an object of a class type with a non-trivial destructor, the program is not required to call the destructor explicitly before the storage which the object occupies is reused or released; however, if there is no explicit call to the destructor or if a delete-expression (5.3.5) is not used to release the storage, the destructor shall not be implicitly called and any program that depends on the side effects produced by the destructor has undefined behavior.

Answer 5

If delete/delete[] is not called for the objects allocated with new/new[], there would be resource leaks. It could be memory leak if the constructor had allocated dynamic memory. Other things like semaphore lock not released, file handles not released etc can happen if the constructor had allocated them.

It will not be undefined behavior.

Answer 6

I dont see how not releasing memory will lead to undefined behaviour. If you dont clean up, the OS still has knowledge of the allocated memory. That will lead to a resource leak for as long as the application runs.