10.10 — The stack and the heap

The memory that a program uses is typically divided into a few different areas, called segments:

  • The code segment (also called a text segment), where the compiled program sits in memory. The code segment is typically read-only.
  • The bss segment (also called the uninitialized data segment), where zero-initialized global and static variables are stored.
  • The data segment (also called the initialized data segment), where initialized global and static variables are stored.
  • The heap, where dynamically allocated variables are allocated from.
  • The call stack, where function parameters, local variables, and other function-related information are stored.

For this lesson, we’ll focus primarily on the heap and the stack, as that is where most of the interesting stuff takes place.

The heap segment

The heap segment (also known as the “free store”) keeps track of memory used for dynamic memory allocation. We talked about the heap a bit already in lesson 9.13 -- Dynamic memory allocation with new and delete, so this will be a recap.

In C++, when you use the new operator to allocate memory, this memory is allocated in the application’s heap segment.

The address of this memory is passed back by operator new, and can then be stored in a pointer. You do not have to worry about the mechanics behind the process of how free memory is located and allocated to the user. However, it is worth knowing that sequential memory requests may not result in sequential memory addresses being allocated!

When a dynamically allocated variable is deleted, the memory is “returned” to the heap and can then be reassigned as future allocation requests are received. Remember that deleting a pointer does not delete the variable, it just returns the memory at the associated address back to the operating system.

The heap has advantages and disadvantages:

  • Allocating memory on the heap is comparatively slow.
  • Allocated memory stays allocated until it is specifically deallocated (beware memory leaks) or the application ends (at which point the OS should clean it up).
  • Dynamically allocated memory must be accessed through a pointer. Dereferencing a pointer is slower than accessing a variable directly.
  • Because the heap is a big pool of memory, large arrays, structures, or classes can be allocated here.

The call stack

The call stack (usually referred to as “the stack”) has a much more interesting role to play. The call stack keeps track of all the active functions (those that have been called but have not yet terminated) from the start of the program to the current point of execution, and handles allocation of all function parameters and local variables.

The call stack is implemented as a stack data structure. So before we can talk about how the call stack works, we need to understand what a stack data structure is.

The stack data structure

A data structure is a programming mechanism for organizing data so that it can be used efficiently. You’ve already seen several types of data structures, such as arrays and structs. Both of these data structures provide mechanisms for storing data and accessing that data in an efficient way. There are many additional data structures that are commonly used in programming, quite a few of which are implemented in the standard library, and a stack is one of those.

Consider a stack of plates in a cafeteria. Because each plate is heavy and they are stacked, you can really only do one of three things:
1) Look at the surface of the top plate
2) Take the top plate off the stack (exposing the one underneath, if it exists)
3) Put a new plate on top of the stack (hiding the one underneath, if it exists)

In computer programming, a stack is a container data structure that holds multiple variables (much like an array). However, whereas an array lets you access and modify elements in any order you wish (called random access), a stack is more limited. The operations that can be performed on a stack correspond to the three things mentioned above:

1) Look at the top item on the stack (usually done via a function called top(), but sometimes called peek())
2) Take the top item off of the stack (done via a function called pop())
3) Put a new item on top of the stack (done via a function called push())

A stack is a last-in, first-out (LIFO) structure. The last item pushed onto the stack will be the first item popped off. If you put a new plate on top of the stack, the first plate removed from the stack will be the plate you just pushed on last. Last on, first off. As items are pushed onto a stack, the stack grows larger -- as items are popped off, the stack grows smaller.

For example, here’s a short sequence showing how pushing and popping on a stack works:

Stack: empty
Push 1
Stack: 1
Push 2
Stack: 1 2
Push 3
Stack: 1 2 3
Stack: 1 2
Stack: 1

The plate analogy is a pretty good analogy as to how the call stack works, but we can make a better analogy. Consider a bunch of mailboxes, all stacked on top of each other. Each mailbox can only hold one item, and all mailboxes start out empty. Furthermore, each mailbox is nailed to the mailbox below it, so the number of mailboxes can not be changed. If we can’t change the number of mailboxes, how do we get a stack-like behavior?

First, we use a marker (like a post-it note) to keep track of where the bottom-most empty mailbox is. In the beginning, this will be the lowest mailbox (on the bottom of the stack). When we push an item onto our mailbox stack, we put it in the mailbox that is marked (which is the first empty mailbox), and move the marker up one mailbox. When we pop an item off the stack, we move the marker down one mailbox (so it’s pointed at the top non-empty mailbox) and remove the item from that mailbox. Anything below the marker is considered “on the stack”. Anything at the marker or above the marker is not on the stack.

The call stack segment

The call stack segment holds the memory used for the call stack. When the application starts, the main() function is pushed on the call stack by the operating system. Then the program begins executing.

When a function call is encountered, the function is pushed onto the call stack. When the current function ends, that function is popped off the call stack. Thus, by looking at the functions pushed on the call stack, we can see all of the functions that were called to get to the current point of execution.

Our mailbox analogy above is fairly analogous to how the call stack works. The stack itself is a fixed-size chunk of memory addresses. The mailboxes are memory addresses, and the “items” we’re pushing and popping on the stack are called stack frames. A stack frame keeps track of all of the data associated with one function call. We’ll talk more about stack frames in a bit. The “marker” is a register (a small piece of memory in the CPU) known as the stack pointer (sometimes abbreviated “SP”). The stack pointer keeps track of where the top of the call stack currently is.

The only difference between our hypothetical mailbox stack and the call stack is that when we pop an item off the call stack, we don’t have to erase the memory (the equivalent of emptying the mailbox). We can just leave it to be overwritten by the next item pushed to that piece of memory. Because the stack pointer will be below that memory location, we know that memory location is not on the stack.

The call stack in action

Let’s examine in more detail how the call stack works. Here is the sequence of steps that takes place when a function is called:

  1. The program encounters a function call.
  2. A stack frame is constructed and pushed on the stack. The stack frame consists of:
    • The address of the instruction beyond the function call (called the return address). This is how the CPU remembers where to return to after the called function exits.
    • All function arguments.
    • Memory for any local variables.
    • Saved copies of any registers modified by the function that need to be restored when the function returns
  3. The CPU jumps to the function’s start point.
  4. The instructions inside of the function begin executing.

When the function terminates, the following steps happen:

  1. Registers are restored from the call stack
  2. The stack frame is popped off the stack. This frees the memory for all local variables and arguments.
  3. The return value is handled.
  4. The CPU resumes execution at the return address.

Return values can be handled in a number of different ways, depending on the computer’s architecture. Some architectures include the return value as part of the stack frame. Others use CPU registers.

Typically, it is not important to know all the details about how the call stack works. However, understanding that functions are effectively pushed on the stack when they are called and popped off when they return gives you the fundamentals needed to understand recursion, as well as some other concepts that are useful when debugging.

A technical note: on some architectures, the call stack grows away from memory address 0. On others, it grows towards memory address 0. As a consequence, newly pushed stack frames may have a higher or a lower memory address than the previous ones.

A quick and dirty call stack example

Consider the following simple application:

The call stack looks like the following at the labeled points:




foo() (including parameter x)



Stack overflow

The stack has a limited size, and consequently can only hold a limited amount of information. On Windows, the default stack size is 1MB. On some unix machines, it can be as large as 8MB. If the program tries to put too much information on the stack, stack overflow will result. Stack overflow happens when all the memory in the stack has been allocated -- in that case, further allocations begin overflowing into other sections of memory.

Stack overflow is generally the result of allocating too many variables on the stack, and/or making too many nested function calls (where function A calls function B calls function C calls function D etc…) On modern operating systems, overflowing the stack will generally cause your OS to issue an access violation and terminate the program.

Here is an example program that will likely cause a stack overflow. You can run it on your system and watch it crash:

This program tries to allocate a huge (likely 40MB) array on the stack. Because the stack is not large enough to handle this array, the array allocation overflows into portions of memory the program is not allowed to use.

On Windows (Visual Studio), this program produces the result:

HelloWorld.exe (process 15916) exited with code -1073741571.

-1073741571 is c0000005 in hex, which is the Windows OS code for an access violation. Note that “hi” is never printed because the program is terminated prior to that point.

Here’s another program that will cause a stack overflow for a different reason:

In the above program, a stack frame is pushed on the stack every time function foo() is called. Since foo() calls itself infinitely, eventually the stack will run out of memory and cause an overflow.

The stack has advantages and disadvantages:

  • Allocating memory on the stack is comparatively fast.
  • Memory allocated on the stack stays in scope as long as it is on the stack. It is destroyed when it is popped off the stack.
  • All memory allocated on the stack is known at compile time. Consequently, this memory can be accessed directly through a variable.
  • Because the stack is relatively small, it is generally not a good idea to do anything that eats up lots of stack space. This includes passing by value or creating local variables of large arrays or other memory-intensive structures.

10.11 -- std::vector capacity and stack behavior
10.9 -- Function Pointers

227 comments to 10.10 — The stack and the heap

  • Pofke1

    As far as I know arrays are allocated on stack and vectors are allocated on heap. So arrays are faster than vectors right? If I need one of them for ~3 000 000 objects which should I choose to enter the data and change it faster?

    • Alex

      > As far as I know arrays are allocated on stack and vectors are allocated on heap.

      It depends. Fixed arrays (e.g. int array[10], or std::array) are allocated on the stack. Dynamically allocated arrays (e.g. int *array = new int[10], or std::vector) are allocated on the heap.

      > So arrays are faster than vectors right? If I need one of them for ~3 000 000 objects which should I choose to enter the data and change it faster?

      Let's be careful here. Allocating memory on the stack is definitely faster than allocating memory on the heap. Accessing memory on the stack may be faster than accessing memory on the heap, but it depends on a lot of factors (including how good your compiler is at optimizing code).

      The size of the stack is also limited. If you need to allocate 3 million objects, you'll definitely want to do so on the heap, because you'll likely overflow your stack if you allocate a fixed array that large.

      • Pofke1

        Thanks Alex!
        And another question: Can something that overflows in my program damage other that program's data or functionality? And is there a way to know if something did overflow?

        • Alex

          Probably not. Modern operating systems will sandbox your application so it can't impact the memory of other running applications or the operating system (both for stability and anti-malware purposes).

          However, there's a small chance that an overflow may cause your program to malfunction, and that could theoretically cause your program could itself do something that had lasting consequence, such as corrupting a resource (e.g. a database or file) by writing bad data to it, or executing some code that has unintended negative effects (e.g. deleting file).

  • Mohammed

    Alex thx for this amazing tutorial.
    However i have a question
    int main()
      int *ptr=new int[10];
    In the above example is pointer ptr stored on heap or stack; Given that you said in the above tutorial
    int *array = new int[10]; // array is assigned 40 bytes in the heap
    which i interpreted to that both the pointer and the dynamically assigned memory are stored on the heap;

  • Matt

    Found a typo:
    "Saved copies of any registered modified by the function that need to be restored when the function returns"

    "registered" should be "registers"

  • Great! Thank you very much. :)

  • Rob H

    "saved copies of any registered modified by the function that need to be restored when the function returns"

    Register modified? Don't understand what is being said.

    • Matt

      Rob, it's saying that the values currently stored in any registers that the function will modify are copied into the stack frame before the function begins. That way, the original values can be restored when the function ends.

  • Harshul

    "Local variables are pushed onto the stack as they are defined" this statement told by you is wrong as told by stack overflows, it says that local variables are not pushed rather they are accessed sequentially as if they are stored one after another ready to be accessed by pointer arithematic

  • Harshul

    Ok i agree with your answer that size limit of heap memory is dependent on OS,RAM and other things.Can we also come up to another explaination that as stack memory is divided into several layer's(stack frames as explained in above tutorial).So stack's each frame's memory also gets reduced but as heap is not divided into bunch of section so we can get much memory as compared to stack.

    I am also a little confused in your explanations first thing expressed above is that the lenght of stack and stack frames is fixed.But as we the stack frame pointer makes the difference the data below the pointer is considered to be in the stack while the rest is waste although that is in the memory but our codes connection to it is broken as our code considers that it is not there and it is popped off.

    Now what happens in case of loops do loops have their own stack which is refreshed after checking of the test condition as the loops have their own scope so it also mean that they should have their own stack.

    One more thing i did not understand your explaination for the stack in action if you can present in a more simpler way.You said "Room is made on the stack for the function’s return type" does this room has a new stack frame or it is there in called function's stack because if it is there in the function's stack then it would be popped off with the funtion stack and return values will never actually return.

    Another thing is that you said "Everything added to the stack after this point is considered “local” to the function" and "Local variables are pushed onto the stack as they are defined" so the local variables and other instructions are pushed on the current stack frame(funtion's frame) as a new frame or it is added to the functions frame.The editing of function frame is not possible as it is in use and can't be edited.Whereas if we consider that they are pushed to the frame then how can function access two local functions simultaneously like in assignment operator,as code can work on one stack at a time.

    And last one in your example of stack overflow you allocated too much memory for the stack to handle and it resulted into an overflow.So it means each frame also has an allocation limit beyond which it can not allocate memory for any variable.It means that if I use one function in my program and declare too many variables then my code is going to crash??

    • Alex

      > Now what happens in case of loops do loops have their own stack which is refreshed after checking of the test condition as the loops have their own scope so it also mean that they should have their own stack.

      Loops don't have their own stack. Variables declared inside nested blocks are still allocated as part of the stack frame, they just aren't accessible until they're in the proper scope.

      I've updated the lesson text about the how return values are handled.

      > so the local variables and other instructions are pushed on the current stack frame(funtion’s frame) as a new frame or it is added to the functions frame

      Both parameters and local variables are included in the function's stack frame.

      > It means that if I use one function in my program and declare too many variables then my code is going to crash??

      Yes. But in reality, this isn't something you really need to worry about, as you'd have to declare an awful lot of variables for this to happen, or fill up your stack in some other inappropriate way first.

  • Harshul

    ->Hey one thing if i try to use any random memory location(not allocated with new operator) with the help of a pointer then it results into an error as it is invalid memory because it is in use by some other program or code.So I wanted to ask that the pointer can allocate any memory apart from the 4 categories you mentioned above i.e. any section of our ram without any restrictions.But if that memory is in use by some other code then our OS restricts the use of such memory and code crashes.

    ->The second thing that i wanted to ask is that what is the size limit of memory allocation in heap.I experimented that i can create an integer array in stack upto the size of 9999 i.e. a[999] whereas in dynamic memory allocation it was possible upto 23 times 9 without resulting into an error in code blocks gnu.So is heap infinitely long or what

    • Alex

      Pointers don't allocate memory. The new operator allocates memory. New will only allocate memory from the heap. I think a pointer can point to memory in any of the areas, so long as it's a section that belongs to your program (note: some areas are read-only).

      The amount of memory that can be allocated on the heap varies based on a number of factors, including OS (and whether it's 32-bit vs 64-bit), whether the application is 32-bit vs 64-bit, physical memory (RAM), hard drive space (for paging), and what other applications are running. It's a complicated topic that is probably better suited for an computer architecture or OS discussion.

  • Cheung Chau

    First of all, thank you for this wonderful site. I first read this site around 2008 or so. However, throughout my career, I have been a Java programmer and then a Python programmer and never really use C++ in any serious way at my work. This site from time to time, let me learn and re-learn C++. Thank you. But, one thing I think it is missing from this site and a lot of introduction book is the different between stack and heap object. Actually, I never see an introduction book mention it. The reason I notice it because in Java, you cannot create a stack object. I think it is an important topic to explore when we learn the new operator or in a section like this.

  • Pablo

    I have a doubt regarding "the stack in action".

    Suppose a function that defines variables "x" and "y", in that order. They are placed on the stack, so "y" is on top. How can the computer access "x" now? (I understood from the analogies that only the element on top could be read?)

    Thanks as always!

    • Alex

      The "element" doesn't need to be a single value, it could be an aggregate (e.g. a structure) containing sub-elements.

      In the case of a function call, that structure would contain things like the function argument values, the return address of the caller, and local parameters....

  • quangtd

    Hi Alex,

    I have a question to heap memory. For example, heap memory which store a lot of value not be released will be clear if the program end?

    • Alex

      Generally modern operating systems will clean up all of the application memory segments (including allocated memory on the heap) when the program ends.

  • puppi

    dear alex,
    so far, i would understand all of documents but i could'nt understand this tutorial. i wonder, can you make a graphical example of stack and heap? or can you give us an example that it shows how to use stack/heap. this section of tutorial is too abstract. may be if you give a code example, that's when we should understand.

  • Benith

    Great tutorial. Wanted to know the exact difference between stack and heap. Learnt a bit more about how function calls work as well. Thanks Alex. keep up the good work.

  • Samir

    Hi Alex,
    Thank you much for such insightful tutorial which is a very good point to start C++ I think.

    I have a question regarding accessing local variables and arguments. From your explanation it looks like we can only access content of the stack based on LIFO mechanism. That means that only last value can be accessed without destroying values on the heap. To access other values on the heap we need to destroy other variables above them.
    However since we can access local variables in any order and even change their values without affecting each other I assume there should be mechanism in addition to LIFO that allow working with local variables.
    I would say LIFO is used for creating function call related staff including local variables and other mechanism is used for working with them.

    • machello

      Each function call creates new activation record or stack frame. The stack frame contains number of local variables, parameters and the return address that the called function needs in order to return to the calling function. After the stack frame is popped, all variables in the stack frame are destroyed. Rigorously speaking, they are not destroyed. The stack pointer points to the new highest active stack frame. The destroyed stack is marked as garbage.

      • Alex

        Yes, the key point here is that we're pushing stack frames onto the call stack, not individual local variables or parameters. We can see everything that exists in the top stack frame, which could include multiple local variables or parameters.

      • Trevor

        Keep in mind that the stack is an area of memory that has been allocated by the operating system, and as such is just as accessible as other memory allocated to the program by the operating system. However different functions do not know where other functions that called them (including main()) have stored their parameters and local variables. If a function or main() records the address of a parameter or local variable (e.g. by setting a pointer to it) and passes this address to a function that it calls, then that function can access that parameter or local variable (using the pointer), even though it is not at the top of the stack.
        When a function is running, it knows where the current stack frame is, and knows where each of its parameters or local variables is within the current stack frame, and therefore can calculate the addresses of these as required, and this allows the function to access all of these variables at will.
        Also keep in mind that each time the function is called, the current stack frame may be at a different location within the stack memory - guaranteed in the case of a recursive function call!

  • bassel

    Hi Alex. great tutorial indeed.

  • Ezo

    Hi. You can add another advantage of stack - it's fast. Stack will be cached primarily so it's faster than other memory places.

  • junker

    "Local variables are pushed onto the stack as they are defined."

    Defined, or declared? Other things I read say declared.

    • Alex

      "defined" and "declared" are typically used interchangeably, as most variable declarations are also variable definitions. However, it's probably more accurate to say they're pushed onto the stack when the function call is executed.

  • donbright

    awesome article!

    the stack size is set on unix with the 'ulimit' command, which often uses 'getrlimit' & other functions internally.

    see also

  • Megan

    All of these tutorials are excellent - and this one in particular! I can't tell you how many sites I've looked at to figure out the difference between the stack/heap and how the stack works, but this makes it so clear!

  • shorawitz

    I'm surprised this hasn't been asked yet, but being a relative noob... I'm wondering what would be considered " large arrays, structures, or classes"? What would a reasonable threshold be?

  • cyberlynxs

    nice explanation

  • ratep90

    Does this mean main() local variables are also on stack?

  • SWEngineer

    Simple well explained tutorial.


  • dospy

    my stack capacity is 258500 :D ( i am on windows, 2gb ram, i dono if it matters anyways )

    #include >iostream< //this looks funny, but the forum wont let me use ""

    #define STACK_CAPACITY 258500

    struct MyStruct
    int nArray[STACK_CAPACITY];
    int main()
    MyStruct anStruct;

    char nChar;

    return 0;

    i have changed the value of STACK_CAPACITY until it reaches the limit,
    when i reached 258500, the program crashed when delcaring nChar

    • Trevor

      Do not forget that int nArray[STACK_CAPACITY] uses 2 or 4 bytes (possible more) for each int, so the stack capacity is at least 517000 or more likely 1,034,000 bytes plus a few more for other overheads.

  • Piyush

    Why can't we make stack as long as heap, if size becomes an issue in case of stacks?

    • Alex

      The stack has to be contiguous in memory, so it has to be preallocated. If the stack were as large as the heap, then the amount of heap memory available would be significantly reduced.

      In reality, the relatively small stack sizes are generally fine, so long as you're aware that you shouldn't allocate large arrays or structures on the stack, or do really deep recursion.

  • What do you mean by "register in the CPU"?
    Please simplify..

    The “marker” is a register in the CPU known as the stack pointer.

  • hello Alex,
    who decides the amount of memory among stack,heap,global & code allocated on ram &
    on what baises.

  • som shekhar

    Since malloc also allocates the size dynamically but it does on stack??? why?

  • Jeff


    This is a really good section, very helpful for me! Quick question:

    Other than writing a function or program to test limits until it crashes, is there an easier to way to determine the size, or amount of memory, allocated to the call stack for a particular program? Wouldn't knowing this in advance help to avoid stack overflow in more complex programs?


    • I won't say there isn't a way to determine the stack size, but I'm not aware of how to do it.

      In reality, the stack is large enough that it's generally not an issue as long as you're aware that you should use dynamic allocation for anything that requires a large amount of memory.

  • Abhishek

    Where can I find the stack in my CPU box?
    Is it a separate hardware or just a space in RAM or Hard disk?

    • According to Wikipedia, "In most modern computer systems, each thread has a reserved region of memory referred to as its stack". So it's just RAM memory being used in a stack-like manner. As soon as the thread/program is killed, that memory can be reused for other stuff.

Leave a Comment

Put all code inside code tags: [code]your code here[/code]