Difference in Heap and Stack.
-
hi all, i want the difference of heap and stack in memory related area. also when you populate the CDialog i am having doubt. CDialog d; ---> First d.DoModel(); CDialog *d = new CDialog; ---->Second d->DoModel(); both First and Second will populate the Dialog but can i know what is the difference of the First and Second Memory Concept. please let me know. Uday kiran
-
hi all, i want the difference of heap and stack in memory related area. also when you populate the CDialog i am having doubt. CDialog d; ---> First d.DoModel(); CDialog *d = new CDialog; ---->Second d->DoModel(); both First and Second will populate the Dialog but can i know what is the difference of the First and Second Memory Concept. please let me know. Uday kiran
uday kiran janaswamy wrote:
difference of heap and stack in memory related area
It's a difference of access memory (the hardware of the memory). The stack is much faster than the heap, but smaller and more expensive. primitives are place in the stack, but objects on the heap.
uday kiran janaswamy wrote:
CDialog d; ---> First d.DoModel();
Object is created on the stack. No chances for memory leak but the amount of memory on the stack is small and the store can get exhausted.
uday kiran janaswamy wrote:
CDialog *d = new CDialog; ---->Second d->DoModel();
Object is created on heap. While allocating memory on the heap you are responsible for deallocating memory. Each byte of memory that's being assigned/used should be returned back to the heap after it's task is done or else there is a problem that is known as Memory Leak.
Somethings seem HARD to do, until we know how to do them. ;-)_AnShUmAn_
-
uday kiran janaswamy wrote:
difference of heap and stack in memory related area
It's a difference of access memory (the hardware of the memory). The stack is much faster than the heap, but smaller and more expensive. primitives are place in the stack, but objects on the heap.
uday kiran janaswamy wrote:
CDialog d; ---> First d.DoModel();
Object is created on the stack. No chances for memory leak but the amount of memory on the stack is small and the store can get exhausted.
uday kiran janaswamy wrote:
CDialog *d = new CDialog; ---->Second d->DoModel();
Object is created on heap. While allocating memory on the heap you are responsible for deallocating memory. Each byte of memory that's being assigned/used should be returned back to the heap after it's task is done or else there is a problem that is known as Memory Leak.
Somethings seem HARD to do, until we know how to do them. ;-)_AnShUmAn_
_AnShUmAn_ wrote:
It's a difference of access memory (the hardware of the memory). The stack is much faster than the heap, but smaller and more expensive. primitives are place in the stack, but objects on the heap.
Really? I always thought memory was memory! Using the stack is generally faster than the heap, since you don't have the overhead of managing a pool of memory. Individual allocations of stack memory cannot be freed, since it's done on a 'frame' basis, and everything in the current frame is cleaned up (albeit sequentially). In the snippet CDialog d; the object itself is stack-based, and will automatically have it's destructor called when the function returns (as the object will go out of scope). In the snippet CDialog* d = new CDialog; the variable is stack-based, but the object itself is on the heap. When the function completes, the variable that refers to the object goes out of scope, but the object still exists, as you say. It will not have a destructor called automatically. There is, AFAICR, nothing which forces primitives to live on the stack, and force objects to be allocated on the heap. Usually the developer decides, particularly in the situation of developing for Windows, where UI objects need to exist beyond the lifetime of a function.
Steve S Developer for hire
-
_AnShUmAn_ wrote:
It's a difference of access memory (the hardware of the memory). The stack is much faster than the heap, but smaller and more expensive. primitives are place in the stack, but objects on the heap.
Really? I always thought memory was memory! Using the stack is generally faster than the heap, since you don't have the overhead of managing a pool of memory. Individual allocations of stack memory cannot be freed, since it's done on a 'frame' basis, and everything in the current frame is cleaned up (albeit sequentially). In the snippet CDialog d; the object itself is stack-based, and will automatically have it's destructor called when the function returns (as the object will go out of scope). In the snippet CDialog* d = new CDialog; the variable is stack-based, but the object itself is on the heap. When the function completes, the variable that refers to the object goes out of scope, but the object still exists, as you say. It will not have a destructor called automatically. There is, AFAICR, nothing which forces primitives to live on the stack, and force objects to be allocated on the heap. Usually the developer decides, particularly in the situation of developing for Windows, where UI objects need to exist beyond the lifetime of a function.
Steve S Developer for hire
hi steve, i understand the concept of stack and heap i am very thankfull to you to give a nice example. Uday kiran
-
_AnShUmAn_ wrote:
It's a difference of access memory (the hardware of the memory). The stack is much faster than the heap, but smaller and more expensive. primitives are place in the stack, but objects on the heap.
Really? I always thought memory was memory! Using the stack is generally faster than the heap, since you don't have the overhead of managing a pool of memory. Individual allocations of stack memory cannot be freed, since it's done on a 'frame' basis, and everything in the current frame is cleaned up (albeit sequentially). In the snippet CDialog d; the object itself is stack-based, and will automatically have it's destructor called when the function returns (as the object will go out of scope). In the snippet CDialog* d = new CDialog; the variable is stack-based, but the object itself is on the heap. When the function completes, the variable that refers to the object goes out of scope, but the object still exists, as you say. It will not have a destructor called automatically. There is, AFAICR, nothing which forces primitives to live on the stack, and force objects to be allocated on the heap. Usually the developer decides, particularly in the situation of developing for Windows, where UI objects need to exist beyond the lifetime of a function.
Steve S Developer for hire
Steve S wrote:
I always thought memory was memory!
In a computer there is only one variable storage area, the main computer RAM. But, for the purpose of organization and performance, it is divided into several areas. When you C/C++ program is started, memory is requested to the operating system to create the heap and the stack. Both these memory areas use what we could call the heap (not the stack). They are accessed by dereferencing pointers, like in the code below: struct S { int x; int y; int z; }; int main(void) { S* var_s; var_s=new S; if (!var_s) return __LINE__; var_s->y=20; } In this code, the structure S will have a total of 12 bytes (in Win32), because each integer takes 4 bytes. The new will return some relatively unpredictable address in memory, which is not that important. The only important value to check for is zero, which means the requested memory is not available (that's why the "if" statement is there). When your program starts, another area of memory is allocated, the stack. This memory is just like any other, but it is considered must more volatile, and besides it is also used where to go to when functions terminate. The stack is considered to be memory like "remember this for a moment while I do something else, and then I will get back to this". 1) The address of the variable var_s is always known by using the stack pointer, which is a physical register of the processor. 2) The stack is very dense. Everything is packed together, and only the memory area after the stack pointer is free. Everything else from the start of the stack up to the stack pointer is densely occupied. 3) All the relative addresses of things stored in the stack are predictable. For example, while inside main, the return address could also be known, independently from where your program came from, by reading memory addresses 5000 to 5003 (4 bytes before the address of var_s). In reality, when main begins there is more stuff added to the stack which makes the var_s ocuppy addresses further from the main return address, but still it is possible to check all variables and function return addresses by navigating through the stack. 4) Although everything is accessible in the stack, by navigating in it, new things can be memorized only after previously memorized things. The stack can contain no holes, and that is the main diference to the heap. So, only the most recent things can be forgotten go release memory for new things. This means
-
Steve S wrote:
I always thought memory was memory!
In a computer there is only one variable storage area, the main computer RAM. But, for the purpose of organization and performance, it is divided into several areas. When you C/C++ program is started, memory is requested to the operating system to create the heap and the stack. Both these memory areas use what we could call the heap (not the stack). They are accessed by dereferencing pointers, like in the code below: struct S { int x; int y; int z; }; int main(void) { S* var_s; var_s=new S; if (!var_s) return __LINE__; var_s->y=20; } In this code, the structure S will have a total of 12 bytes (in Win32), because each integer takes 4 bytes. The new will return some relatively unpredictable address in memory, which is not that important. The only important value to check for is zero, which means the requested memory is not available (that's why the "if" statement is there). When your program starts, another area of memory is allocated, the stack. This memory is just like any other, but it is considered must more volatile, and besides it is also used where to go to when functions terminate. The stack is considered to be memory like "remember this for a moment while I do something else, and then I will get back to this". 1) The address of the variable var_s is always known by using the stack pointer, which is a physical register of the processor. 2) The stack is very dense. Everything is packed together, and only the memory area after the stack pointer is free. Everything else from the start of the stack up to the stack pointer is densely occupied. 3) All the relative addresses of things stored in the stack are predictable. For example, while inside main, the return address could also be known, independently from where your program came from, by reading memory addresses 5000 to 5003 (4 bytes before the address of var_s). In reality, when main begins there is more stuff added to the stack which makes the var_s ocuppy addresses further from the main return address, but still it is possible to check all variables and function return addresses by navigating through the stack. 4) Although everything is accessible in the stack, by navigating in it, new things can be memorized only after previously memorized things. The stack can contain no holes, and that is the main diference to the heap. So, only the most recent things can be forgotten go release memory for new things. This means
You aren't telling me anything I didn't already know (I've programmed in 6502, Z80, MC68000 and 80x86 assembly language). My point was that stack memory isn't physically faster per se than the heap, since it's all stored in the same stuff (although cache hits on the stack region are more likely to succeed). Sure, a stack allocation is much faster, since you don't have to worry about maintaining coherence or multiple threads running parallel allocation/deallocation, and deallocation is likewise easier. That's why stack-based variables are/were referred to in Kernighan and Ritchie as 'auto' or 'automatic' variables. Space is automatically allocated and deallocated on request. You do make the point, of course, that the stack isn't limitless, and a couple of questions I've seen posted on CP were resolved by changing to use dynamic rather than automatically allocated variables. However, I felt that the comment on speed was likely to confuse the OP, and lead them away from the facts...
Steve S Developer for hire
-
You aren't telling me anything I didn't already know (I've programmed in 6502, Z80, MC68000 and 80x86 assembly language). My point was that stack memory isn't physically faster per se than the heap, since it's all stored in the same stuff (although cache hits on the stack region are more likely to succeed). Sure, a stack allocation is much faster, since you don't have to worry about maintaining coherence or multiple threads running parallel allocation/deallocation, and deallocation is likewise easier. That's why stack-based variables are/were referred to in Kernighan and Ritchie as 'auto' or 'automatic' variables. Space is automatically allocated and deallocated on request. You do make the point, of course, that the stack isn't limitless, and a couple of questions I've seen posted on CP were resolved by changing to use dynamic rather than automatically allocated variables. However, I felt that the comment on speed was likely to confuse the OP, and lead them away from the facts...
Steve S Developer for hire
Thanks for the information Steve. I got to know a few more things through this thread. Thanks once again....
Somethings seem HARD to do, until we know how to do them. ;-)_AnShUmAn_