Heap vs Stack allocations

[Martin Dickopp]

void f1(int n) { vector<int> x(n); /* C++ */ }

void f2(int n) { int x[n]; /* C99 only */ }

void f3(int n) { int* x = new int[n]; /* C++ */ delete [] x; }

void f4(int n) { int* x = (int*)malloc(n*sizeof(int));
/*...*/ free(x); }


In all of these cases it makes sense for the compiler to allocate x
on the stack instead of the heap. However, AFAIK, only in case of f2
the compiler is required to do so.

No, neither in C nor in C++ a heap and/or stack is even required to
exist. How/where the implementation allocates memory is unspecified.

I find it quite strange that C++ doesn't require a stack to exist, but
OTOH dictates that when an exception occurs, "stack unwinding" is done.
This term doesn't have a meaning if there is no stack, does it?

How the C++ standard uses the term "stack unwinding" is defined in 15.2#3:

| The process of calling destructors for automatic objects constructed on
| the path from a try block to a throw-expression is called "stack
| unwinding."

Except for the STL class stack, I don't see the term "stack" used in any
other sense in the standard. Therefore, you are correct that a stack in
the above sense is required to exist, but there is no requirement that a
stack to allocate memory for objects with automatic storage duration from
must exist.

Martin

 

[E. Robert Tisdale]

I find it quite strange that
C++ doesn't require a stack to exist
but, OTOH, dictates that
when an exception occurs, "stack unwinding" is done.

Does "automatic storage unwinding" make any sense to you?

This term doesn't have a meaning if there is no stack, does it?

I agree. You would need to be *very* generous in you interpretation.
Perhaps, it means something like,
"If the implementation uses the program stack,
stack unwinding is done when an exception occurs."

Textbooks and standards documents are full of "sloppy" language.
They are, after all, the product of mere mortals and not Holy Scripture.

 

[Mark McIntyre]

void f1(int n) { vector<int> x(n); /* C++ */ }
void f2(int n) { int x[n]; /* C99 only */ }
void f3(int n) { int* x = new int[n]; /* C++ */ delete [] x; }
void f4(int n) { int* x = (int*)malloc(n*sizeof(int));
/*...*/ free(x); }

In all of these cases it makes sense for the compiler to allocate x on
the stack instead of the heap.

Why do you care? You don't need to know.....

However, AFAIK, only in case of f2 the
compiler is required to do so.

Um, since C doesnt require a compiler to use a heap or stack, then not
even f2 is required to use it.

Without learning assembly, is there any
way to see how a particular compiler handles each of these cases?

The existence of a heap or stack is utterly implementation dependent
and therefore depends on finding a means to monitor how your
implementation does something. A good debugger might help.

However the fundamental question is: why do you care? If you use the
knowledge of how your current compiler does it, then your code is
almost guaranteed to break when the maker upgrades it.

 

[Rob Thorpe]

Hello



void f1(int n) { vector<int> x(n); /* C++ */ }

void f2(int n) { int x[n]; /* C99 only */ }

void f3(int n) { int* x = new int[n]; /* C++ */ delete [] x; }

void f4(int n) { int* x = (int*)malloc(n*sizeof(int));
/*...*/ free(x); }



In all of these cases it makes sense for the compiler to allocate x on
the stack instead of the heap. However, AFAIK, only in case of f2 the
compiler is required to do so. Without learning assembly, is there any
way to see how a particular compiler handles each of these cases?

Best wishes,
MSG

Although it is not in the C standard there is a function called
'alloca' that does this. Linux, all modern Unix implementaions and MS
Windows provide it.

y = alloca(x);

Allocates x bytes and gives a pointer to them. They are deallocated
at the end of the function.

The MS Windows version is called "_alloca"

It's not gauranteed to be faster than malloc, or in fact implemented
on the stack (I've come across it implemented on the heap) but it
normally is.

Personally I wish it was in the C standard, but it's not, because it
is hard to implement universally (on machines without stacks). So if
you want to know more post the question elsewhere, or email me
directly.

I wouldn't worry much about speed of memory allocation anyway, or
really about fragmentation, mallocs are good these days. But I do use
alloca because it demonstrates my intentions clearly i.e. that the
memory stops being used at the end of the function.