Memory Leak

[18hRX9L8]

Would the code below leak memory?
^{_{Warning: Do not run the code.}}

#include <cstdio>

int memleak(int size)
{
	char* leaker=new char[size];
	return size;
}

int main(void)
{
	short leaksize;
	char termch;
	printf("This program leaks memory...\n");
	printf("How many bytes would you like to leak?  ");
	scanf("%d%c",&leaksize,&termch);
	printf("%d bytes leaked.",memleak(leaksize));
}

[Zaita]

No.

[ne555]

Yes.

[Daleth]

Warning: Do not run the code.

I found this older thread with a similar issue. Hope it helps.
http://www.cplusplus.com/forum/beginner/61526/

[jim80y]

In total contradiction to @Zaita, yes it does.

I think what he was (unhelpfully) trying to indicate was that after leaking the memory at line 16, the program immediately exits so it's not really leaked for very long.

[Edit - technically, it's leaking at line 6]

But yes, if you had a lot of code being executed after line 16, you would have a leak.

Jim

[Zaita]

@jimB0y to be technically a correct would have to be continual. This is not. It's a 1 time allocation of memory that is not properly cleaned up.

In his example, as you pointed out this is not a leak because he simply allocates it once then quits. Even if the application ran for another 24 hours this would not be considered a leak as the memory usage over time would not increase.

Edit: Most profiling tools would classify this as a leak because the memory is not being cleaned up properly. This is usually done as an indication of a potential bug because you have forgotten to clean up objects etc, not because it is truly leaking memory

[jim80y]

So a memory leak is only a memory leak if it leaks more than once during a program's life?

That's not true - any memory that's been allocated and subsequently lost is a leak.

Jim

[writetonsharma]

This is actually a memory leak example on a small scale.

This is how memory leaks.. allocating memory and not releasing or allocating memory and then overwriting the pointer with other pointer..
if this was a huge program of 1 million lines and each function start to use memory and not clean it.. the memory is going to rise with time because the memory is not released and only taken.

The program is closing and so why should we care about releasing because the OS is going to do it for you is so funny...

Edit: I wonder what a memory leak is if this is not... :)))

[Stewbond]

It means that you lose your pointer to some allocated memory. The OS has reserved this memory for you and now you've lost it's address. If you keep doing that, you'll see your system run out of memory.

Example, open your task manager/system monitor and run this:

int main()
{
    while(true)
    {
        int* ptr = new int[1000];
    }
    return 0;
}

Just watch your computer's memory slowly die. Just make sure that you kill the process before anything very bad happens. Worst-case, you'll need to reboot.

[writetonsharma]

The computer would get slow but may be the program would crash because the OS would not allocate memory after some limit.

[Zaita]

The program is closing and so why should we care about releasing because the OS is going to do it for you is so funny...

The reason is because the memory MAY hold information in a buffer than relies on the de-allocation of an object and it's destructor being called. (e.g you have a file writing class that flushes the buffer and closes the file handle in the destructor).

The computer would get slow but may be the program would crash because the OS would not allocate memory after some limit.

On 64bit OS this limit is HUGE. You're system would likely fail to allocate once the swap/pagefile size hits the currently allocated maximum.

So a memory leak is only a memory leak if it leaks more than once during a program's life?

That's not true - any memory that's been allocated and subsequently lost is a leak.

The allocation of memory and then losing the pointer to it causes this block of memory to be unusable yes, but it's not "leaking" memory because this never happens more than once, so the amount of memory is not leaking (getting larger). Obviously this is bad because it's a waste of memory but it's not actually going to have any negative effects on the application running unless it continually leaks and forces memory to be swapped (massive performance hit).

Still my answer to his original question is no. But the question itself is pointless because you should be relying on the use of smart pointers for 99% of your development now anyways (the 1% would be for system calls and APIs that do not support smart pointers)

[cire]

The allocation of memory and then losing the pointer to it causes this block of memory to be unusable yes, but it's not "leaking" memory because this never happens more than once, so the amount of memory is not leaking (getting larger).

You're playing with words. The memory cannot be recovered, therefore it is leaked.

If the function in the OP is called twice, the second time it does the same thing as it does the first time -- it leaks.

If it only happens one time, the amount of memory is leaking (the amount of unrecoverable memory got larger than it was before it was.. um.. leaked.)

[writetonsharma]

but it's not actually going to have any negative effects on the application running unless it continually leaks and forces memory to be swapped (massive performance hit).

we are here talking about if its a memory leak and not about performance. So, even if a single byte, its a memory leak. Once the function returns (in the current program), the address cannot be recovered and so its a leak.

But the question itself is pointless because you should be relying on the use of smart pointers for 99% of your development now anyways

Not everyone in this world uses libraries for heap management and auto heap management also doesn't fit everywhere. So, I would say your statement is not close to be true. :-)

[18hRX9L8]

So to sum it all up, after time, the program will allocate enough to stop the OS from working. Also, make sure you that when you allocate memory, make sure to deallocate memory.

[Zaita]

@usandfriends no it'll slow the OS down, but the OS will likely kill the application by preventing it from allocating memory.

Not everyone in this world uses libraries for heap management and auto heap management also doesn't fit everywhere. So, I would say your statement is not close to be true. :-)

You don't need libraries for smart pointers. They have been available natively since C++98 TR1. They're more available now in C++11. That aside, the majority of professional developers SHOULD be proficient with Boost which also provides smart pointers. There is very little practical rationale to have not been using them for some time.

[writetonsharma]

@Zaita - I think you should review what you are saying if you are a professional developer.
Looks like you start using anything which is available in market without thinking if that fits into the requirements or if that would be useful.

All this discussion reminds me a section from windows programming book by charles petzold. Chapter-20 - New! Improved! Now with Threads! Have a look if you have a chance and you will know what you are saying.

C++11 - not all compilers are mature enough for its support. Not all code in this world is written after 2011.. a 10 million lines of code cannot be ported to c++11 overnight and neither its necessary.

Boost - How its necessary/should to be be used by every developer or a product/project or every developer should know boost is far from anyone's thinking. please explore, there are many better libraries in the market. Neither are smart pointers essential for each code base.

[Zaita]

@writeonsharma you neglect the fact that smart pointers were introduced in C++98 TR1. Drafted in 2005 and published in 2007.

Regarding boost. All developers should be familiar with it as it is so widely used in the industry and pieces of Boost have been used in C++98 TR1 and C++11. Many of Boost's founders are also members of the C++ standards committee.

Also, C++11 was in draft before 2010 as it was originally called C++0X. Compilers started offering parts of the functionality it before it was published in 2011. That aside, as I mentioned C++98 TR1 introduced smart pointers, and boost has been around for many years as well.

I think you would do better to do research on the history of the C++ standards, common libraries and their associations with the C++ standards committees and when functionality was available in a language.

[Daleth]

Maybe you two should take this debate to General C++ or the Lounge instead of reviving a solved thread?

[writetonsharma]

@Zaita - you have the last word. You won!!! :-)

@Daleth - Thanks. I rest my case. :-)