Jump to content
  • Advertisement
Sign in to follow this  
nuclear123

stack/heap question!

This topic is 2887 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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!

Share this post


Link to post
Share on other sites
Advertisement
The old dead value generally remains around in memory until the memory allocator allocates it again for something else. However the page of memory was in might also be freed by the allocator and then it would not be there anymore at all, and accidentally dereferencing the old stale pointer will generate an access violation of some kind.

Share this post


Link to post
Share on other sites
Depends on the environment. If its managed code in .net, the gc will reclaim and free when it finds that no pointers reference if.

Share this post


Link to post
Share on other sites
It is most certainly not known that the variable would amount to some location in memory after it is destroyed. First of all a local variable may not have any memory space designated for it as it may be optimised into a register. When that happens the very next operation on any variable could, and in fact likely would, overwrite that register value.
Worst of all, the variable might be optimised away entirely, as would most likely be the case in your sample program.

Secondly if it was designated some location in memory, another variable that has a non-overlapping scope with that variable could also be designated the same memory location, so when that other variable comes into scope and is assigned to, that location is changed.
A compiler could even ensure that when a variable goes out of scope that any memory designated for it is intentionally set to some specific value such as 0xCCCCCCCC, though in practice I don't know of this occurring.

When it comes to memory from the heap, the moment you free it, the memory could, and in fact will with certain debug runtimes, be immediately overwritten.

When a variable goes out of scope or is freed, you can neither be sure that the value is erased from memory, nor can you be sure it is still there.

Share this post


Link to post
Share on other sites


when variable x goes out of scope, it's value remains in memory correct?
Generally, no. When variable goes out of scope it's permanently lost, so is its value.

Under some compilers, the value may linger around for a while, but that is just a coincidence.

Example: variable might be loaded into register and is never written in memory at all.

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?[/quote]Maybe. It depends. The behavior is not prescribed.

C++ is required not to incur hidden costs. So while it will generally not clean the memory that was released on heap, there is no reason debug allocator couldn't/wouldn't do that.

Memory managed languages might indeed zero out memory on release to amortize the cleanup cost. When a new instance is allocated it is then known to be allocated from memory block filled with zeros making it properly initialized.


There is a reason why this behavior in C/C++ is called "undefined". Any assumption will be valid only given each specific build (compiler/OS/switches).

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!