Heap vs Stack allocations

[MSG]

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

[Martin Dickopp]

ms*****@yahoo.c om (MSG) writes:

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.
Without learning assembly, is there any way to see how a particular
compiler handles each of these cases?

- Consult the compiler documentation.
- Ask the compiler vendor.
- For each combination of compiler and platform you have in mind, ask in a
newsgroup dedicated to that compiler/platform.

Martin

[E. Robert Tisdale]

MSG wrote:

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?
However, AFAIK, only in case of f2, the compiler is required to do so.
Without learning assembly, is there any see
how a particular compiler handles each of these cases?

Yes.

Storage for array x is allocated from the free store (the "heap")
in all cases except f2.
Automatic storage is allocated (from the stack) in f2 for array x
if you use a C99 compliant C compiler or a C or C++ compiler
that supports variable size arrays as an extension to C89 or C++.

A new C++ standard has been drafted
but I don't think that it specifies support for variable size arrays ...
yet.

[J. J. Farrell]

ms*****@yahoo.c om (MSG) wrote in message news:<54******* *************** ****@posting.go ogle.com>...

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.
Are you saying that C99 introduced a requirement that implementations
have a stack? I'm surprised.
Without learning assembly, is there any
way to see how a particular compiler handles each of these cases?

Not in Standard C. A particular compiler might have a way to do it,
but you'd need to ask in a newsgroup that discussed that compiler.
I've no idea about C++.

[E. Robert Tisdale]

J. J. Farrell wrote:

[snip]

Are you saying that C99 introduced a requirement
that implementations have a stack? I'm surprised.

I don't think so.
Just substitute the phases "automatic storage" for "stack"
and "free store" for "heap" and the question will make sense.
I don't think that the question really has anything to do with
the implementation of automatic or free storage.

[Jack Klein]

On Thu, 22 Jan 2004 16:27:11 -0800, "E. Robert Tisdale"
<E.************ **@jpl.nasa.gov > wrote in comp.lang.c:

MSG wrote:

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?

However, AFAIK, only in case of f2, the compiler is required to do so.
Without learning assembly, is there any see
how a particular compiler handles each of these cases?

Yes.

No, there is no requirement in either C or C++ that anything be
allocated on "the stack", or even that there is one.
Storage for array x is allocated from the free store (the "heap")
in all cases except f2.
The term "free store" has meaning in C++. It has no such meaning in
C, not being defined by the language standard at all. The C standard
does not specify where allocated memory comes from, nor how it is
managed.
Automatic storage is allocated (from the stack) in f2 for array x
if you use a C99 compliant C compiler or a C or C++ compiler
that supports variable size arrays as an extension to C89 or C++.
Neither C nor C++ even mentions a "stack", nor requires that one
exist.
A new C++ standard has been drafted
but I don't think that it specifies support for variable size arrays ...
yet.

The OP quite plainly knows that C++ does not have variable size
arrays.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.l earn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Martin Dickopp]

"E. Robert Tisdale" <E.************ **@jpl.nasa.gov > writes:

MSG wrote:

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?

However, AFAIK, only in case of f2, the compiler is required to do so.
Without learning assembly, is there any see
how a particular compiler handles each of these cases?

Yes.

Storage for array x is allocated from the free store (the "heap")
in all cases except f2.

That statement is correct in the same sense that "storage for array x
is allocated on Mars in all cases except f2" is correct. Since f2 is
the only case where an array x appears, no statement about array x in
all cases except f2 can be false.

Martin

[MSG]

"E. Robert Tisdale" <E.************ **@jpl.nasa.gov > wrote in message news:<40******* *******@jpl.nas a.gov>...

MSG wrote:

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?

LOL! A fella from JPL should know this, so listen good :-)

1. Stack allocation/deallocation is MUCH faster than heap -
approximately O(1) vs O(log(n)), where n is the number of allocated
pieces, IIRC.

2. Heap can become fragmented (unless you move memory blocks around,
which C/C++ does not usually do AFAIK), so allocating can fail long
before your memory is exhausted, OTOH stack allocation will always
succeed as long as you have enough stack left.

BTW, #2 can be a source of "interestin g" behavior when your program
works fine for a while, but then starts acting funny. This however
happens only to software of a certain degree of quality, most C/C++
programs (*) will crash long before heap fragmentation becomes an
issue. LOL.

Best wishes,
MSG

* those written by present company excluded, of course

[Joona I Palaste]

MSG <ms*****@yahoo. com> scribbled the following
on comp.lang.c:

"E. Robert Tisdale" <E.************ **@jpl.nasa.gov > wrote in message news:<40******* *******@jpl.nas a.gov>...

MSG wrote:

> 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?

LOL! A fella from JPL should know this, so listen good :-) 1. Stack allocation/deallocation is MUCH faster than heap -
approximately O(1) vs O(log(n)), where n is the number of allocated
pieces, IIRC. 2. Heap can become fragmented (unless you move memory blocks around,
which C/C++ does not usually do AFAIK), so allocating can fail long
before your memory is exhausted, OTOH stack allocation will always
succeed as long as you have enough stack left. BTW, #2 can be a source of "interestin g" behavior when your program
works fine for a while, but then starts acting funny. This however
happens only to software of a certain degree of quality, most C/C++
programs (*) will crash long before heap fragmentation becomes an
issue. LOL.

Did you *read* the other replies? Neither C or C++ specifies that a
"stack" or a "heap" even exists. Trollsdale is only trying to
intentionally ignore this and discuss implementation details on
comp.lang.c. If you want to discuss a particular implementation, find
a newsgroup for that implementation.

--
/-- Joona Palaste (pa*****@cc.hel sinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"There's no business like slow business."
- Tailgunner

[MSG]

"E. Robert Tisdale" <E.************ **@jpl.nasa.gov > wrote in message news:<40******* *******@jpl.nas a.gov>...

MSG wrote:

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?

LOL! A fella from JPL should know this, so listen good :-)

1. Stack allocation/deallocation is MUCH faster than heap -
approximately O(1) vs O(log(n)), where n is the number of allocated
pieces, IIRC.

2. Heap can become fragmented (unless you move memory blocks around,
which C/C++ does not usually do AFAIK), so allocating can fail long
before your memory is exhausted, OTOH stack allocation will always
succeed as long as you have enough stack left.

BTW, #2 can be a source of "interestin g" behavior when your program
works fine for a while, but then starts acting funny. This however
happens only to software of a certain degree of quality, most C/C++
programs (*) will crash long before heap fragmentation becomes an
issue. LOL.

Best wishes,
MSG

* those written by present company excluded, of course