heap, stack
-
Hi, These two word always appear in my book, for example, There is a class called CFn. And... 1> CFn fn; // this will create an object fn in stack 2> CFn* pFn=new CFn(); // this will create an object in heap My problem is the advantages and disvantages of an object created in heap vs in stack. Plz explain them in detail. Thank you in advance. Best regard. I confess that I am a stubborn guy, but why not put things thoroughly, logically and systematically clean. One concrete prolem is worth a thousand unapplied abstractions.
-
Hi, These two word always appear in my book, for example, There is a class called CFn. And... 1> CFn fn; // this will create an object fn in stack 2> CFn* pFn=new CFn(); // this will create an object in heap My problem is the advantages and disvantages of an object created in heap vs in stack. Plz explain them in detail. Thank you in advance. Best regard. I confess that I am a stubborn guy, but why not put things thoroughly, logically and systematically clean. One concrete prolem is worth a thousand unapplied abstractions.
When you create an object on the stack, you are basically creating a variable in the current stack frame in which you are operating. Stack varaibles automatically go away when you exit the function call that they were defined in. The heap is where dynamic memory is allocated from. When you declare an object on the heap, you have to allocate memory for it, usually with
newormalloc, or in the case of the windows APIGlobalAlloc. The pointer that you recieve from one of these allocations will not be destroyed until you explicitly destroy it. You can destroy heap memory that you have previously allocated withdelete,free, orGlobalFree, each of these calls corresponding to the allocators that I mentioned earlier. The advantages of the stack is that you do not have to manage the memory, just declare the variable and start using it. It will clean up after itself when the function exits. The disadvantage is that you have to know how much memory that you need at compile time, and the variables that you declare are not persistent outside of the function that they are described in. The advantage of the heap is that you can decide how much memory that you need at runtime, and the variables will persist as long as you need them.
Checkout my Guide to Win32 Paint for Intermediates
-
Hi, These two word always appear in my book, for example, There is a class called CFn. And... 1> CFn fn; // this will create an object fn in stack 2> CFn* pFn=new CFn(); // this will create an object in heap My problem is the advantages and disvantages of an object created in heap vs in stack. Plz explain them in detail. Thank you in advance. Best regard. I confess that I am a stubborn guy, but why not put things thoroughly, logically and systematically clean. One concrete prolem is worth a thousand unapplied abstractions.
The previous comments are correct, but one of the things most often forgotten about stack .vs. heap allocation is speed: stack allocation basically requires moving the stack pointer (register) to allocate a block of memory. Heap allocation includes overhead that can range from simple management of heap blocks and can go so far as to involve the operating system to request more free pages of memory. Stack allocation of memory is much faster than heap allocation, and heap allocation is much slower than stack allocation. That is why you never treat
CStringorCComBSTRobjects like they were free! Also, the hidden information in the previous comment about stack memory cleaning itself up is that you should never pass the address of a stack-allocated variable to a function that may store that pointer. By the time that function gets around to using that pointer, the memory that the pointer points to will be invalid. Worse yet, it might not crash when it uses that pointer, it might just corrupt another function's local variables. Lastly, heap access is normally serialized, which prevents two threads from messing with (allocating or deallocating memory) the heap at once, and that is good (but is the cause of a small part of the slwoing overhead). However, if you are doing any serious multithreaded development, you need to be careful of how you (mis)use dynamically allocated memory, and maybe even create seperate heaps for your threads, to reduce the effects of heap contention. Threads each get their own stack, so their stack allocations to not effect other threads. Peace! -=- James. -
The previous comments are correct, but one of the things most often forgotten about stack .vs. heap allocation is speed: stack allocation basically requires moving the stack pointer (register) to allocate a block of memory. Heap allocation includes overhead that can range from simple management of heap blocks and can go so far as to involve the operating system to request more free pages of memory. Stack allocation of memory is much faster than heap allocation, and heap allocation is much slower than stack allocation. That is why you never treat
CStringorCComBSTRobjects like they were free! Also, the hidden information in the previous comment about stack memory cleaning itself up is that you should never pass the address of a stack-allocated variable to a function that may store that pointer. By the time that function gets around to using that pointer, the memory that the pointer points to will be invalid. Worse yet, it might not crash when it uses that pointer, it might just corrupt another function's local variables. Lastly, heap access is normally serialized, which prevents two threads from messing with (allocating or deallocating memory) the heap at once, and that is good (but is the cause of a small part of the slwoing overhead). However, if you are doing any serious multithreaded development, you need to be careful of how you (mis)use dynamically allocated memory, and maybe even create seperate heaps for your threads, to reduce the effects of heap contention. Threads each get their own stack, so their stack allocations to not effect other threads. Peace! -=- James.****James R. Twine wrote: heap access is normally serialized I think you mean "synchronized". :) /ravi "There is always one more bug..." http://www.ravib.com ravib@ravib.com
-
****James R. Twine wrote: heap access is normally serialized I think you mean "synchronized". :) /ravi "There is always one more bug..." http://www.ravib.com ravib@ravib.com
Ravi Bhavnani wrote: I think you mean "synchronized". Quoted from MSDN docs: "
To ensure thread safety, the heap has to serialize access to itself" and "The default behavior is to serialize access to the heap". True, a synchronization object is used for this. The difference is that "Serialization" basically means "one thing after the other, and one at a time". "Synchronization" usually involves multiple threads at work, where two threads can actually try to manipulate something at the same time. Although I agree as much as to say that the two terms are often used interchangeably... Peace! -=- James.