Is it better to use heap or stack variables?

Question

An experienced C++ user told me that I should strive for using heap variables, i.e.:

A* obj = new A("A");

as opposed to:

A obj("A");

Aside from all that stuff about using pointers being nice and flexible, he said it's better to put things on the heap rather than the stack (something about the stack being smaller than the heap?). Is it true? If so why?

NB: I know about issues with lifetime. Let's assume I have managed the lifetime of these variables appropriately. (i.e. the only criteria of concern is heap vs. stack storage with no lifetime concern)

Answer 1

Depending on the context we can consider heap or stack. Every thread gets a stack and the thread executes instructions by invoking functions. When a function is called, the function variables are pushed to stack. And when the function returns the stack rollbacks and memory is reclaimed. Now there is a size limitation for the thread local stack, it varies and can be tweaked to some extent. 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. Besides this if the object is to be accessed by multiple threads then storing such object on stack makes no sense.

Thus small variables, small objects who's size can be determine at compile time and pointers should be stored on stack. The concern of storing objects on heap or free store is, memory management becomes difficult. There are chances of memory leak, which is bad. Also if application tries to access an object which is already deleted, then access violation can happen which can cause application crash.

C++11 introduces smart pointers (shared, unique) to make memory management with heap easier. The actual referenced object is on heap but is encapsulation by the smart pointer which is always on the stack. Hence when the stack rollbacks during function return event or during exception the destructor of smart pointer deletes the actual object on heap. In case of shared pointer the reference count is maintained and the actually object is deleted when the reference count is zero. http://en.wikipedia.org/wiki/Smart_pointer

Answer 2

Stack = Static Data allocated during compile time. (not dynamic)

Heap = Dyanamic Data allocated during run time. (Very dynamic)

Although pointers are on the Stack...Those pointers are beautiful because they open the doors for dynamic, spontaneous creation of data (depending on how you code your program).

(But I'm just a savage, so why does it matter what i say)

Answer 3

The answer is not as clear cut as some would make you believe.

In general, you should prefer automatic variables (on the stack) because it's just plain easier. However some situations call for dynamic allocations (on the heap):

• unknown size at compile time
• extensible (containers use heap allocation internally)
• large objects

The latter is a bit tricky. In theory, the automatic variables could get allocated infinitely, but computers are finite and worse all, most of the times the size of the stack is finite too (which is an implementation issue).

Personally, I use the following guideline:

• local objects are allocated automatically
• local arrays are deferred to std::vector<T> which internally allocates them dynamically

it has served me well (which is just anecdotal evidence, obviously).

Note: you can (and probably should) tie the life of the dynamically allocated object to that of a stack variable using RAII: smart pointers or containers.

Answer 4

Simply put, don't manage your own memory unless you need to. ;)

Answer 5

There are no general rules regarding use of stack allocated vs heap allocated variables. There are only guidelines, depending on what you are trying to do.

Here are some pros and cons:

Heap Allocation:

Pros:

• more flexible - in case you have a lot of information that is not available at compile-time
• 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

Cons:

• slower - dynamic allocation is usually slower than stack allocation
• 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
• 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()

Stack allocation:

Pros:

• faster - which is important mostly on embedded systems (I believe that for embedded there is a MISRA rule which forbids dynamic allocation)
• does not cause memory fragmentation
• makes the behavior of applications more deterministic - e.g. removes the possibility to run out of memory at some point
• less error prone - as the user is not needed to handle deallocation

Cons:

• less flexible - you have to have all information available at compile-time (data size, data structure, etc.)
• smaller in size - however there are ways to calculate total stack size of an application, so running out of stack can be avoided

I think this captures a few of the pros and cons. I'm sure there are more.

In the end it depends on what your application needs.

Answer 6

C++ has no mention of the Heap or the Stack. As far as the language is concerned they do not exist/are not separate things.

As for a practical answer - use what works best - do you need fast - do you need guarantees. Application A might be much better with everything on the Heap, App B might fragment OS memory so badly it kills the machine - there is no right answer :-(

Answer 7

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 fact, the lifespan of object created on the stack and on the heap is different:

• The local variables of a function or a code block {} (not allocated by new), are on the stack. They are automatically destroyed when you are returning from the function. (their destructors are called and their memory is freed).
• But, if you need something an object to be used outside of the the function, you will have to allocate in on the heap (using new) or return a copy.

Example:

 void myFun()
 {
   A onStack; // On the stack
   A* onHeap = new A(); // On the heap
   // Do things...

 } // End of the function onStack is destroyed, but the &onHeap is still alive

In this example, onHeap will still have its memory allocated when the function ends. Such that if you don't have a pointer to onHeap somewhere, you won't be able to delete it and free the memory. It's a memory leak as the memory will be lost until the program end.

However if you were to return a pointer on onStack, since onStack was destroyed when exiting the function, using the pointer could cause undefined behaviour. While using onHeap is still perfectly valid.

To better understand how stack variables are working, you should search information about the call stack such as this article on Wikipedia. It explains how the variables are stacked to be used in a function.

Answer 8

It is always better to avoid using new as much as possible in C++.
However, there are times when you cannot avoid it.
For ex:
Wanting variables to exist beyond their scopes.

So it should be horses for courses really, but if you have a choice always avoid heap allocated variables.