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

问题:

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.

回答1:

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

回答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.

回答3:

Referring to [basic.stc.dynamic.deallocation] (aka 3.7.4.2 in n3337) there are only 4 paragraphs.

1. operator delete and operator delete[] should be either class members or in global scope
2. Precisions on the valide signatures of operator delete and operator delete[]
3. Precisions on which delete can be used for deallocation, depending on which new was used for allocation
4. Precisions on the possible arguments value and effects of the call (ie the pointers to this storage are now invalid)

There is absolutely no note here on what would happen if storage is allocated but never released.

I don't think that the Standard concerns itself with this, so it is more unspecified rather than undefined.

回答4:

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.

回答5:

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)

回答6:

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.

回答7:

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.