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!
stack/heap question!
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.
Depends on the environment. If its managed code in .net, the gc will reclaim and free when it finds that no pointers reference if.
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.
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.
Generally, no. When variable goes out of scope it's permanently lost, so is its value.
when variable x goes out of scope, it's value remains in memory correct?
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?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).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
