Why would you ever want to allocate memory on the heap rather than the stack? [duplicate]

Answer 1

just to add you can use alloca to allocate memory on the stack, but again memory on the stack is limited and also the space exists only during the function execution only. that does not mean everything should be allocated on the heap. like all design decisions this is also somewhat difficult, a "judicious" combination of both should be used.

Answer 2

Stack variables (often called 'automatic variables') is best used for things you want to always be the same, and always be small.

int x;
char foo[32];

Are all stack allocations, These are fixed at compile time too.

The best reason for heap allocation is that you cant always know how much space you need. You often only know this once the program is running. You might have an idea of limits but you would only want to use the exact amount of space required.

If you had to read in a file that could be anything from 1k to 50mb, you would not do this:-

int readdata ( FILE * f ) {
  char inputdata[50*1024*1025];
  ...
  return x;
}

That would try to allocate 50mb on the stack, which would usually fail as the stack is usually limited to 256k anyway.

Answer 3

1. You want an allocation to live beyond a function invocation
2. You want to conserve stack space (which is typically limited to a few MBs)
3. You're working with re-locatable memory (Win16, databases, etc.), or want to recover from allocation failures.
4. Variable length anything. You can fake around this, but your code will be really nasty.

The big one is #1. As soon as you get into any sort of concurrency or IPC #1 is everywhere. Even most non-trivial single threaded applications are tricky to devise without some heap allocation. That'd practically be faking a functional language in C/C++.

Answer 4

So I want to make a string. I can make it on the heap or on the stack. Let's try both:

char *heap = malloc(14);
if(heap == NULL)
  {
    // bad things happened!
  }
strcat(heap, "Hello, world!");

And for the stack:

char stack[] = "Hello, world!";

So now I have these two strings in their respective places. Later, I want to make them longer:

char *tmp = realloc(heap, 20);
if(tmp == NULL)
  {
    // bad things happened!
  }
heap = tmp;
memmove(heap + 13, heap + 7);
memcpy(heap + 7, "cruel ", 6);

And for the stack:

// umm... What?

This is only one benefit, and others have mentioned other benefits, but this is a rather nice one. With the heap, we can at least try to make our allocated space larger. With the stack, we're stuck with what we have. If we want room to grow, we have to declare it all up front, and we all know how it stinks to see this:

char username[MAX_BUF_SIZE];

Answer 5

Besides manual control of object's lifetime (which you mentioned), the other reasons for using heap would include:

• Run-time control over object's size (both initial size and it's "later" size, during the program's execution).

For example, you can allocate an array of certain size, which is only known at run time.

With the introduction of VLA (Variable Length Arrays) in C99, it became possible to allocate arrays of fixed run-time size without using heap (this is basically a language-level implementation of 'alloca' functionality). However, in other cases you'd still need heap even in C99.

• Run-time control over the total number of objects.

For example, when you build a binary tree stucture, you can't meaningfully allocate the nodes of the tree on the stack in advance. You have to use heap to allocated them "on demand".

• Low-level technical considerations, as limited stack space (others already mentioned that).

When you need a large, say, I/O buffer, even for a short time (inside a single function) it makes more sense to request it from the heap instead of declaring a large automatic array.

Answer 6

The stack and heap share the same "open" memory space and will have to eventually come to a point where they meet, if you use the entire segment of memory. Keeping the balance between the space that each of them use will have amortized cost later for allocation and de-allocation of memory a smaller asymptotic value.