stack/heap question

[lochnessmonster]

i understand when you use memory on the heap, your program allocates new memory to it to be used...the stack is preallocated memory and when u put a local variable on the stack, and the variables goes out of scope/dies, it technically still stays in memory until you overwrite the previous value correct?

for example

stack:
int main()
{
{
int x = 3;
}
return 0;
}

when variable x goes out of scope, it's value remains in memory correct? we just loose access/the pointer to it! correct?

think about the same situation but we use the heap. if i allocate new memory dynamically in my program using the heap, then later delete the memory location in the pointer, is the memory freed back to the O/S and the value still remain in that memory block that was used? or is it wiped clean when it is restored back to the O/S for use? hope this wasnt confusing and thanks alot!

[Narue]

it technically still stays in memory until you overwrite the previous value correct?

That's one valid result, yes.

is the memory freed back to the O/S and the value still remain in that memory block that was used?

That's also a valid result, conceptually. The problem with these questions is that the answer varies depending on the implementation.

[mike_2000_17]

>>or is it wiped clean when it is restored back to the O/S for use?
No, it would be wasteful to "clean" the memory. In fact, what does "clean" really mean.. setting all bits to 0? or to 1? or to some other pattern? The next process or chunk of code that is going to use that piece of memory will ignore whatever was there before, so it doesn't matter to what values the bits are set to in the free blocks of memory because nobody cares. It is almost always like that with computer memory. For example, when you delete a file from your harddrive, it doesn't wipe the memory clean, it simply removes the entry for that file in the filesystem (the part of the harddrive that keeps are record of all the files and folders). That way, the file is virtually unaccessible and effectively deleted, but its memory is still there (at least until new files are written and possibly overwrite that memory). Even formatting the harddrive won't wipe out this memory (usually only creates a new empty filesystem).

As Narue said, the heap mechanisms are usually highly dependent on the implementation. However, there is another possibility that is often the case when you delete memory allocated from the heap. That is, the memory is released back to the heap, but not to the OS. The heap usually gets a chunk of memory from the OS and then allocates parts of that chunk to the program per request. When it runs out of space in that chunk of memory it got from the OS, it will ask for more. When the program has deallocated a large amount of memory from the heap, the heap might release some chunks back to the OS. So, in summary, the relation between the dynamic memory used by the program and the memory used by the heap is not a 1 to 1 correspondence. Usually, in steady operation of your program, the heap will look like a swiss cheese and will use a bit more RAM memory than what your program actually uses. Again, this is implementation dependent, some small operating systems might do the dynamic allocation directly from a global OS heap that manages all the RAM (at least, I know Windows and Linux don't do it this way because it is not manageable if you have too many applications running and too much RAM to handle, but for small operating systems on, say, for a micro-controller, it could be a viable option).

All in all, I think your understanding of it is correct. Technically, you could say that at the instant after a stack variable has gone out of scope or at the instant after a chunk of dynamically allocated memory has been deleted, the memory is still intact but no longer accessible (at least not through good programming practices). But, frankly, it's useless to know this because you cannot use it. Even though, at that instant, the memory might be intact, at any moment later, the memory could have been overwritten (even by the time you reach the next line of code). The one useful thing to know is that the memory stored in a "fresh" variable, i.e. uninitialised memory, is not zero or some other specific value, it is "random" memory (i.e. it will be the residual values of whatever variables existed at that place in memory before, which could be anything). One caveat though, some implementations, in debug mode only, will initialise fresh memory (stack or heap) to a specific pattern such that you can more easily see, during an run-time error report, that the values of your variables correspond to an uninitialised value, these patterns are usually 4 byte hex phrases like 0xBAADF00D and others (note that Windows system calls sometimes use those hex phrases too, which is stupid IMO).