Heap and Stack

 Name: Don Arnett
Date: August 9, 2004 at 10:26:22 Pacific

http://www.computing.net/answers/programming/heap-vs-stack/11004.html

Reply:
Why "nevermind the differences"? Understanding the differences will help you make these decisions yourself.

I will assume that you know what the stack is for, so won't describe that:

 

Stack:
- local variables (variables declared inside a function) are put on the stack - unless they are also declared as 'static' or 'register'
- function parameters are allocated on the stack
- local variables that are declared on the stack are not automatically initialized by the system so they usually have garbage in them until you set them
- variables on the stack disappear when the function exits (thus, if a function is called multiple times, it's local variables and parameters are recreated and destroyed each time the function is called end exited).

 

Heap:
- declared variables (as opposed to dynamically created ie new, malloc) are created on the heap before program execution begins, they exist the entire life of the program (although scope may prevent access to them - they still exist) and they are initialized to all zeros
- global variables are on the heap
- static local variables are on the heap (this is how they keep their value between function calls)
- memory allocated by new, malloc and calloc are on the heap

So now, on to the question of where to put your arrays. You want to consider:

- the size - the stack has a limit size, so large arrays should be allocated in the heap. Sometimes having too many local variables or large local arrays will cause stack overflow errors
- do you want the values held between function calls (if yes, put on heap, if not, can be on stack)
- is initialization of the array time consuming (if yes, may want to put on heap so that you have to initialize only once)

Remember that using 'new' rather than 'normal declaration' is not the only way to move variables from the stack to the heap:

- you can make a local variable static - this puts it on the heap but keeps the scope local to the function - remember it keeps it's value between function calls
- you can make it global - but scope allows 'everyone' to access it.

 

So let's look at your three specific examples:

- an array of 2 elements
I wouldn't worry about it. Make it local and thus on the stack.

- an array of 2000 elements
I'd usually make this global or allocate with new to keep the stack size down. But if it's a small program, who cares.

- 100 arrays of 2 elements
I wouldn't make 100 arrays of 2 elements. I'd make a 2 dimensional array (100x2) and probably put on the heap. Since you normally want to avoid global variables, I'd consider putting it on the heap by using dynamic allocation or making it static and initializing only the first time thru the array. BUt it partially depends upon what is stored in the array and how dynamic the data is.

This is a quick response to a not trivial question. Hope it helps some.
 

=======================================================

http://www.ucosoft.com/2008/01/12/stack-vs-heap.html

The stack is much more efficient than the heap.

Simple rule: Use the stack when you can.

 

You cannot use the stack if you need the object in other functions. (Stack allocations are deleted when the function that allocated them returns.)

You cannot use the stack if you need a variable size. Stack allocations use a constant size that must be known at compile time.

 

When you define an object (class instance) on the stack, it is automatically deleted (its destructor is called) when the class instance goes out of scope.

Instead, when you allocate on the heap, you must pay attention to properly cleanup the object (else you will have memory or resources leaks).

 

For example:

 

<code>

  // ** Stack Allocation **
  {
      // Allocate MyClass instance on the stack
      MyClass c;

      … use c

  } // c destructor called by C++ compiler

 

  // ** Heap Allocation **
  {
      // Allocate on the heap
      MyClass * ptrC = new MyClass();

      …use heap-allocated instance
      ptrC->DoSomething(…);

  } // Destructor *not* called here! Memory leak!
   // Must do an explicit delete ptrC;

</code>

 

However, if you use smart pointers, like boost:: or tr1:: shared_ptr, you can safely allocate on the heap, and let the smart pointer pay attention to free the object it is referencing. (So, with shared_ptr, you can safely allocate on the heap, and kind of “forget” about freeing the object. It’s kind of C# or Java garbage collection…)

 

Recently, Visual C++ Team released a kind of “Service Pack 0″ for VS2008, which includes the useful shared_ptr class, and also other great things. I recall that David C. posted the link on this newsgroup recently. You can read something also here:

http://blogs.msdn.com/vcblog/archive/2007/12/26/just-what-is-this-tr1…

 

In general, if you have a small objects, you can allocate on the stack. Instead, if you want to allocate big memory, you should allocate on the heap (the stack is a limited resource, more limited than the heap).

Note also that there are classes like C++ STL container classes (e.g. std::vector) that you allocate on the stack. But the class implementation internally can allocate the required memory on the heap, e.g.:

  std::vector< double > someData(1000);

The vector class instance (’someData’) is allocated on the stack (so you don’t have to call its destructor explicitly), but the vector data (the 1000 double values) is allocated on the heap internally by std::vector implementation.