Is not calling delete on a dynamically allocated o

Question

From the discussion started here, I'd like to know whether the following code has a memory leak:

int main()
{
   new int();
   //or
   int* x = new int();
   return 0;
}

I know the memory is reclaimed by the OS, but is it a leak anyway? I believe it is.

What defines a memory leak? I could only find one reference in the standard, and it wasn't very helpful.

EDIT: I don't want to start a debate - "I think that..." is not the kind of answer I'm looking for. I'm mostly interested in sources - what C++ books or websites or whatever have to say about it.

Answer 1

Second case is not a memory leak.
It is not a leak because you still have an pointer to the memory that was allocated.
To define a memory leak I would like to stick to definition which most of memory analysis tools like valgrind use:

Memory was allocated and cannot be subsequently freed because the program no longer has any pointers to the allocated memory block.

Answer 2

I would define a memory leak this way

a) it takes memory

b) it is no more useful for the application

c) it is no more accessible, and therefore no more deleteable

According to this I would judge your sample as memory leak. Your sample show an uncritical leak. A critical leak is continuous taking memory, what could happen until the application crashes

Answer 3

It is subjective/debatable.

In my opinion there are two levels of resource (memory is one of the resources provided by OS) leaks: OS-level and Application Level. Please note that names are custom and there might be a better suitable technical term for them.

Application-level leak ceases to exist once application terminates because OS cleans application's mess. I.e. once application is nuked, threat to OS stability is gone. On decent operating system memory allocations in applications can only produce "application-level" leak.

OS-level leak will not cease to exist once application terminates. Normally some other resources fall into that category (files), but not memory. However, I cannot guarantee that there is no operating system/platform that doesn't clean up leaked memory. By murphy's law there probably is such platform used even today.

So when I say/write "memory leak" I'm talking about application-level leak - any memory allocation that is not explicitly deleted by APP. Every allocation, even intentional, falls into category. Also, normally memory allocation profilers and similar tools will complain about your "intentional leaks",

So, yes, your code has a leak.

In my opinion, making leaks even on purpose, even when you're certain that OS will free them is a bad idea because it encourages sloppy coding and one day you'll fail to delete class that releases something importan in its destructor that can't be cleaned up by OS automatically. Given amount of junk left in windows registry and temporary files folder on average PC, many programmers routinely use that technique for resources that aren't cleaned up by OS properly. So the best idea would be to avoid making leaks.

Answer 4

It depends on how you define "leak". According to the most obvious definition, and the only useful one, it is not a leak, at least at the application level. A bucket doesn't leak because you intentionally allow a finite quantity of water to escape. And practically speaking, an application doesn't fail because you intentionally allow a bound set of objects to persist beyond the end of the program.

With regards to memory leaks, our perception of the word has been colored by "leak checkers"---programs like Purify or Valgrind. Their role is to find leaks (amongst other things), but they have no way of knowing what is intentional, and what isn't, and what is bound, and what isn't. So they invent other definitions: an object which is unreachable has "leaked" (and there's a good probability in real code that that's true), or an object which hasn't been deleted after all of the destructors of static objects have been executed has "leaked". In this latter case, the definition is obviously wrong, and sort of useless. But there are enough cases where such things are leaks that it is reasonable to at least warn about them ("possible leaks"), provided there is a way of filtering out specific cases. (Both Purify and Valgrind recognize that not all of these cases are really leaks, and provide various filtering mechanisms for their detection.) All of which is well and good—I'm very happy that we have such tools—but we shouldn't allow them to pervert the language.

And one final reminder: the standard says that the standard iostream objects (std::cout, etc.) will never be destructed. So any buffers they allocate will (probably) never be freed. Certainly no one in their right mind would consider these "leaks".

Answer 5

Yes, there is a leak of 4 bytes because memory allocated by new is not deleted and during the life of the application it is a leak.

From this link:

http://www.yolinux.com/TUTORIALS/C++MemoryCorruptionAndMemoryLeaks.html

Memory leak description: Memory is allocated but not released causing an application to consume memory reducing the available memory for other applications and eventually causing the system to page virtual memory to the hard drive slowing the application or crashing the application when than the computer memory resource limits are reached. The system may stop working as these limits are approached.

Answer 6

The above code does indeed have a leak. More importantly, however, if instead of allocating an int, you allocated a special object, say a server connection object, if you never properly clean up and call delete, the object's destructor is never run, which might be important if your server connection needs to perform special clean up code (write to files, etc).

In your specific example, the leak is of no consequence since main immediately exits (effectively) and the memory is freed back to the OS. In writing production code, however, you should definitely not leave any leaks (even one as trivial as above) since the code might get moved around into a different function, and the leak could actually propagate itself through the programs lifetime.

Also, perhaps the most important thing to consider is what you the programmer consider to be a memory leak. You should consider memory as a resource that should be managed according to your own model. Consider reading this article which discusses some resource allocation and management models. Consider RAII (resource acquisition is initialization) and smart pointers (or at least the idea of smart pointers and the idea of reference counting).