0

I've always thought that heap allocation is needed for allocating data structures with sizes that aren't known at compile time. But I recently learned about alloca, which allows for dynamic allocation on the stack. So, if heap allocation isn't needed for allocation of dynamic sizes, are there things for which heap allocation is necessary? My first thought is that resizing data structures may be difficult, but I'm not sure whether it's impossible or not without using the heap.

awelkie
  • 2,422
  • 1
  • 22
  • 32

3 Answers3

1

If you restrict yourself to using the stack for memory then you restrict the lifetime of your data to the lifetime of the scope they were conceived in. Yes you could make them global but then you have a fixed amount of memory for your data.

How about we reserve a large chunk of global memory? Well now you are just emulating the heap in a memory wasteful way.

DrYap
  • 6,525
  • 2
  • 31
  • 54
1

It's about live time. Objects on the heap live until you free() them. Objects allocated with alloca live in the current stack frame until your function returns.

Resizing of data on the heap will cause a new allocation if the first allocation did not reserve sufficcient memory. This will give the first heap item back to the free list. That is impossible in the stack frame. There is no realloc pendant.

BTW: There is no need that objects on the heap are of dynamic size. The function signature of malloc takes a size parameter that allows you to calculate the size at run-time. But you often allocate object without a dynamic size. e.g.

typedef struct {
    int a;
    char s[3];
} example;

example *ex = malloc(sizeof(example));
free(ex);

Edit: Although you could allocate again and again on the stack unless you get a stackoverflow the semantic differs from realloc. It wouldn't be possible to give the space back when a realloca should allocate the for a larger size. It's even impossible to shrink the size. The reason for both is the mechanismn how alloca works. There is no free list and there are no chunks on the stack that are managed like heap objects. It's just changing the stack pointer that gives space for the result of alloca.

harper
  • 13,345
  • 8
  • 56
  • 105
  • I think you mean there is no `realloca` function. It would be possible to create such a function (it would simply always allocate a new allocation of the larger size without free'ing the original allocation until the the leaving that stack frame such as by `return` or `longjmp`), but given the typically short(er) life of stack-based allocations, it generally is not necessary. – mctylr Dec 12 '14 at 18:26
0

Heap is not necessary, double is not necessary, int is not necessary, all that is needed is 0 and 1 and a Turning Machine.

Different programming models exists to efficiently create and maintain code. Code could exist with just about everything on the stack. Depending on how the OS/environment is set up, the stack does not run out any faster than heap. Memory is memory - it is just that typical OS's put more stringent limits on the stack size as it is more likely that code needing large stack is errant than correct.

Processors tend to be designed that way too, allowing a large, but limited stack, and a relatively enormous dynamic data space.

So for now, live with performing most variable large size allocations via malloc() and save alloca() for niche applications. Maybe in 20 years everything will be on the stack due to Dr. Whippersnapper latest programming model.

chux - Reinstate Monica
  • 143,097
  • 13
  • 135
  • 256