memory allocation

Yes, you must delete ressources. And you must do so before you reassign the only pointer pointing to them, otherwise you can't do that anymore.

Simply said: what you have here is one giant memory-leak.

i would assume that u would not have to delete it sense it is released off the stack after the function returns. Also, how could u delete it ne ways. You can't do stuff after the return statement anyways. But that might not be the case. Your char *a is pointing to the memory allocated when u created the variable in the function. I would suggest that you try and delete a and see wat happens. Or just get a program that monitors your ram and watch wat happens to it as you run your program.

Hope this helps,

Jake

Quote:

Original post by jake_Ghost i would assume that u would not have to delete it sense it is released off the stack after the function returns. Also, how could u delete it ne ways. You can't do stuff after the return statement anyways. But that might not be the case. Your char *a is pointing to the memory allocated when u created the variable in the function. I would suggest that you try and delete a and see wat happens. Or just get a program that monitors your ram and watch wat happens to it as you run your program. Hope this helps, Jake

The pointer itself is stored on the stack, and goes out of scope at the closing brace, but the array of 100 chars is stored on the heap, and exists until it is deleted using "delete [] pointerToChar", where pointerToChar points to the allocated memory, such as "str", or "a". It is also free'd on program shutdown by the operating system.

Quote:

Original post by ludo8x If the app run for a while, will it fullfill the central memory ? Should i delete the pointer returned outside the function ? At the end of the application the memory is automatically released even if i do not delete nothing ?

Yes. It'll take about 25165824 iterations to do it though. Your app has roughly 3Gb of memory it can use, thanks to windows using virtual memory. So, your app will end up causing the hard drive to thrash when it begins to run out of physical RAM and Windows desperately tries swapping things in and out of RAM to make room. If you have Windows 2000, or Windows XP, you can look at the task manager while your app is running to see how much memory it's using (roughly).
It's generally bad form to return a pointer from a function that needs to be deleted. Because it means you have to remember to delete it, and if theres someone else using your code, it's easy to cause memory leaks like that.
Yes, all memory is freed when the applications exits. Otherwise Windows would end up in a huge mess if lots of apps did that.

Quote:

Yes. It'll take about 25165824 iterations to do it though. Your app has roughly 3Gb of memory it can use, thanks to windows using virtual memory.

Let's hope he's not using WindowsXP-64 [lol]

Quote:

Original post by Wildfire Quote: Yes. It'll take about 25165824 iterations to do it though. Your app has roughly 3Gb of memory it can use, thanks to windows using virtual memory. Let's hope he's not using WindowsXP-64 [lol]

Hmm... Assuming you lose a gig in 64-bit mode (as you do in 32-bit mode, roughly), that gives you... [whips out windows calculator]... 144115188067467264 iterations :P
Of course I have absolutely no idea if that works out, or if you happen to have 16777216 Terrabytes of disk space [smile]

Uahah, i caused a giant-memory leak! that's funny :D

Tnx to everyone!

This is one reason to make use, where possible, of standard library objects which wrap things that would "normally" (read "by old-fashioned C hackers") be done with a pointer to something. In particular, for textual data, this means std::string.

while (true) {  std::string foo = "foo"; // the string object allocates some dynamic memory*  foo += "bar"; // the string object possibly does a new allocation and throws                // away the old one automatically*} // The string object's destructor is implicitly called, which automatically // makes the appropriate delete[] call for any new[] it might have done.

No leaks, no fuss, no muss.

* The string object might not actually do dynamic allocation for a short string, but instead use a small internal buffer until the string gets longer. This is an implementation detail; in any event, all you really need to know is that you won't leak memory using these things, because they are written to do proper management of the memory that they ask for.