Re: On VLAs and incomplete types

On Mar 21, 11:55 am, Sensei <Sensei's e-mail is at Mac-dot-com> wrote:
On 2008-03-21 16:19:10 +0100, Ben Bacarisse <ben.use...@xxxxxxxxx> said:





Is x allocated on the
fly as we enter the code block (somehow, on the heap or by any other
non C-related means)

Well put.  How or where does not matter.  It is likely to allocated
from a stack ("the" stack if the compiler is using only one).

and then subsequently freed when exit?

The way I used to put it was: the storage lasts until the program flow
passes the end of the variable's scope (unless the program exits before
that).  It is surprisingly hard to get the words exactly right, but
most people find the intent more natural than the wording used to
explain it!

Then what
are the advantages (not counting the "syntactic sugar" I can think of)
of having VLAs into the standard?

It allows you to have arrays of variable size, efficiently allocated.
malloc and free will usually be slower and you need to do the freeing.
The real advantage, though, comes with code like your 2D array
parameter called C.  Such things are simpler with VLA parameters.

Well, I think you clarified a lot. Thanks!

One last question, you are saying that VLAs are "usually" faster than
the malloc/free counterpart, although arrays are passed by means of
pointers. How can it be so, if the array lives as long as the code
block it refers to is executing? I mean, the code will effectively
allocate and deallocate memory, so there must be an explanation for
being faster. Is heap and stack actually different in this?

As for 2D arrays, I'm using a simple array with appropriate indexing,
is there a performance reason for preferring a variable length array?

Automatic variables are typically placed on a *cough* stack. The
generation of these variables is really just a simple subtraction.
The generation of dynamic memory is more complicated and requires
functions to track the allocations carefully.
The speed of access will be similar between automatic and dynamically
allocated memory. It is the book keeping of generation and disposal
that differ significantly.

So why not just use automatic memory all the time? It is a very
limited resource, and when it fails, it does not fail gracefully like
malloc() which will tell you that something went wrong by returning an
NULL pointer. If an automatic allocation fails you can expect a core
dump or some sort of undefined behavior.



Thanks for bearing with me :)

.

Relevant Pages

  • Re: run-time vs compile-time
    ... > offset related to some location (like stack base) somewhere. ... > offset from heap to pi. ... When you allocate an int on the heap, it is allocated at address 1. ... application has a given amount of memory it can use as it wishes. ...
    (alt.comp.lang.learn.c-cpp)
  • Re: run-time vs compile-time
    ... > offset related to some location (like stack base) somewhere. ... > offset from heap to pi. ... When you allocate an int on the heap, it is allocated at address 1. ... application has a given amount of memory it can use as it wishes. ...
    (comp.lang.cpp)
  • Re: Doubt on Stack variables.
    ... Will it allocate memory for all the char's together or allocate for ... this only second char in the function gets memory. ... As other posters have pointed out, the notion of a "stack" does not appear ... the stack limits) would run into these limits. ...
    (comp.lang.c)
  • Re: style question,itoa
    ... able to allocate buffers in some convenient location the callee ... dynamically allocate a block of memory and computing this size to use ... call might require allocating a page for the stack. ... " Checking every single malloc in a bigger application for possible ...
    (comp.unix.programmer)
  • Re: hacker challenge - traverse a list
    ... He means that you can use as much additional memory as you like, ... any Osolution can use a stack of arbitrary bounds by mapping ... even misused computational complexity theory does not ... Harter's test by pointing out that a program with a large array ...
    (comp.programming)