In fact, the lifespan of object created on the stack and on the heap is different: The stack should be prefered to the heap, as stack allocated variables are automatic variables: their destruction is done automatically when the program goes out of their context. In the end it depends on what your application needs. I think this captures a few of the pros and cons. smaller in size - however there are ways to calculate total stack size of an application, so running out of stack can be avoided.less flexible - you have to have all information available at compile-time (data size, data structure, etc.).less error prone - as the user is not needed to handle deallocation.removes the possibility to run out of memory at some point makes the behavior of applications more deterministic - e.g.faster - which is important mostly on embedded systems (I believe that for embedded there is a MISRA rule which forbids dynamic allocation).harder to maintain - as you know each dynamic allocation must be followed by a deallocation, which should be done by the user - this is error prone as there are a lot of cases where people forget to match every malloc() call with a free() call or new() with delete().may cause memory fragmentation - allocating and deallocating objects of different sizes will make the memory look like Swiss cheese :) causing some allocations to fail if there is no memory block of the required size available.slower - dynamic allocation is usually slower than stack allocation.bigger in size - you can allocate more - however, it's not infinite, so at some point your program might run out of memory if allocations/deallocations are not handled correctly.more flexible - in case you have a lot of information that is not available at compile-time.There are only guidelines, depending on what you are trying to do. There are no general rules regarding use of stack allocated vs heap allocated variables. In case of shared pointer the reference count is maintained and the actually object is deleted when the reference count is zero. Hence when the stack rollbacks during function return event or during exception the destructor of smart pointer deletes the actual object on heap. The actual referenced object is on heap but is encapsulation by the smart pointer which is always on the stack. Also if application tries to access an object which is already deleted, then access violation can happen which can cause application crash.Ĭ++11 introduces smart pointers (shared, unique) to make memory management with heap easier. There are chances of memory leak, which is bad. The concern of storing objects on heap or free store is, memory management becomes difficult. Thus small variables, small objects who's size can be determine at compile time and pointers should be stored on stack. Besides this if the object is to be accessed by multiple threads then storing such object on stack makes no sense. Considering this if every object is created on stack and the object requires large memory, then the stack space will exhaust resulting to stackoverflow error. Now there is a size limitation for the thread local stack, it varies and can be tweaked to some extent. And when the function returns the stack rollbacks and memory is reclaimed. When a function is called, the function variables are pushed to stack. Every thread gets a stack and the thread executes instructions by invoking functions. Depending on the context we can consider heap or stack.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |