Heap vs Stack allocations

Discussion in 'C++' started by MSG, Jan 22, 2004.

  1. MSG

    MSG Guest

    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
     
    MSG, Jan 22, 2004
    #1
    1. Advertising

  2. (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
     
    Martin Dickopp, Jan 23, 2004
    #2
    1. Advertising

  3. 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.
     
    E. Robert Tisdale, Jan 23, 2004
    #3
  4. (MSG) wrote in message news:<>...
    >
    > 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++.
     
    J. J. Farrell, Jan 23, 2004
    #4
  5. 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.
     
    E. Robert Tisdale, Jan 23, 2004
    #5
  6. MSG

    Jack Klein Guest

    On Thu, 22 Jan 2004 16:27:11 -0800, "E. Robert Tisdale"
    <> 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.learn.c-c++
    http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
     
    Jack Klein, Jan 23, 2004
    #6
  7. "E. Robert Tisdale" <> 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
     
    Martin Dickopp, Jan 23, 2004
    #7
  8. MSG

    MSG Guest

    "E. Robert Tisdale" <> wrote in message news:<>...
    > 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 "interesting" 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
     
    MSG, Jan 23, 2004
    #8
  9. MSG <> scribbled the following
    on comp.lang.c:
    > "E. Robert Tisdale" <> wrote in message news:<>...
    >> 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 "interesting" 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 () ------------- Finland --------\
    \-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
    "There's no business like slow business."
    - Tailgunner
     
    Joona I Palaste, Jan 23, 2004
    #9
  10. MSG

    MSG Guest

    "E. Robert Tisdale" <> wrote in message news:<>...
    > 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 "interesting" 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
     
    MSG, Jan 23, 2004
    #10
  11. MSG

    CBFalconer Guest

    MSG wrote:
    > <> wrote in message
    > > 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 :)

    .... snip ...

    You are obviously not acquainted with our resident Trollsdale.
    His advice and queries are normally nonsense, and even his quotes
    are not to be trusted. He edits them, and totally changes their
    meaning, without any annotation. I seriously doubt that he has
    any connection with jpl or nasa, his alleged knowledge is just too
    erroneous. However he may be a janitor there (which is perfectly
    respectable, just not normally computer knowledgeable).

    --
    Chuck F () ()
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE worldnet address!
     
    CBFalconer, Jan 23, 2004
    #11
  12. Jack Klein wrote:

    > The term "free store" has meaning in C++.
    > It has no such meaning in C,


    Nonsense!
    It has exactly the same meaning that it has in C++.

    > not being defined by the [ANSI/ISO C] language standard at all.


    Nonsense!

    void free(void *ptr);

    is defined by ANSI/ISO C[89]9.

    > The C standard does not specify where allocated memory comes from


    Really?
    Can a C program "steal" the memory that is allocated?
     
    E. Robert Tisdale, Jan 23, 2004
    #12
  13. On Fri, 23 Jan 2004 09:31:43 GMT, in comp.lang.c , CBFalconer
    <> wrote:

    >meaning, without any annotation. I seriously doubt that he has
    >any connection with jpl or nasa, his alleged knowledge is just too
    >erroneous.


    There apparently /is/ an ERTisdale there (his name has appeared on
    some research papers). But that doesn't mean that /this/ ERT works
    there, or even that this guy /is/ ERT. Its easy enough to fake up the
    headers. After all, for all I know, you're a lesbian trucker from
    Vermont called Shirley, and not a mongolian cat-skinner living in a
    squat in Eastbourne at all.

    Myself however, I believe he is the real thing. I met some VERY
    self-opinionated research people when I was a postgrad, some of whom
    thought that because they were (say) experts in the properties of
    plasma in 30T torsional magnetic fields, they were naturally experts
    in any other field of human endeavour. Given that many of them had
    failed to master the art of washing their beards, wore shoes with
    velcro and (aged 25) took all their laundry home to their mum every 8
    weeks....

    >However he may be a janitor there (which is perfectly
    >respectable, just not normally computer knowledgeable).


    You obviously don't read Dilbert.....

    Never *ever* sass the garbage man....
    --
    Mark McIntyre
    CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
    CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>


    ----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
    http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
    ---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
     
    Mark McIntyre, Jan 23, 2004
    #13
  14. MSG

    MSG Guest

    Joona I Palaste <> wrote in message news:<buqlb3$1fl$>...
    > MSG <> scribbled the following
    > on comp.lang.c:
    > > "E. Robert Tisdale" <> wrote in message news:<>...
    > >> 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 "interesting" 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

    ^^^^^^^^^^

    It's not very nice of you. This is an international forum, so you need
    to learn to be more tolerant of others' opinions, including opinions
    as to what is on-topic.

    "Love thy neighbor" - Mr. Fix It

    > 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.
     
    MSG, Jan 23, 2004
    #14
  15. MSG

    Alan Balmer Guest

    On 23 Jan 2004 14:49:24 -0800, (MSG) wrote:

    >It's not very nice of you. This is an international forum, so you need
    >to learn to be more tolerant of others' opinions, including opinions
    >as to what is on-topic.


    No. Topicality does not depend on nationality.

    --
    Al Balmer
    Balmer Consulting
     
    Alan Balmer, Jan 23, 2004
    #15
  16. MSG

    Rolf Magnus Guest

    Martin Dickopp wrote:

    > (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.


    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?
     
    Rolf Magnus, Jan 24, 2004
    #16
  17. MSG

    Rolf Magnus Guest

    E. Robert Tisdale wrote:

    > Jack Klein wrote:
    >
    >> The term "free store" has meaning in C++.
    >> It has no such meaning in C,

    >
    > Nonsense!
    > It has exactly the same meaning that it has in C++.


    Could you quote the part that defines it? I didn't find it.

    >> not being defined by the [ANSI/ISO C] language standard at all.

    >
    > Nonsense!
    >
    > void free(void *ptr);
    >
    > is defined by ANSI/ISO C[89]9.


    Yes it is. But what does the free() function have to do with the term
    "free store"? I searched though the C99 standard, and no single
    occurance of "free store" was found.
    The C++ standard does use it, but it doesn't actually define the term
    "free store". It just indicates that it ("free store") is the memory
    where dynamic objects are allocated.

    >> The C standard does not specify where allocated memory comes from

    >
    > Really?


    Well, if it does, can you quote the part that dictates the location of
    that memory?

    > Can a C program "steal" the memory that is allocated?


    The C standard neither requires nor forbids an implementation to provide
    a way to "steal" memory, whatever that means.
     
    Rolf Magnus, Jan 24, 2004
    #17
  18. MSG

    osmium Guest

    Rolf Magnus writes:

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


    Sounds like a bit of poetic justice for pedants to me. :)
     
    osmium, Jan 24, 2004
    #18
  19. On 23 Jan 2004 14:49:24 -0800, in comp.lang.c ,
    (MSG) wrote:

    >Joona I Palaste <> wrote in message news:<buqlb3$1fl$>...
    >> MSG <> scribbled the following
    >> on comp.lang.c:


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

    >>
    >> Did you *read* the other replies? Neither C or C++ specifies that a
    >> "stack" or a "heap" even exists. Trollsdale is only trying to

    > ^^^^^^^^^^
    >It's not very nice of you. This is an international forum, so you need
    >to learn to be more tolerant of others' opinions, including opinions
    >as to what is on-topic.


    Whats on topic here in CLC is not a matter of opinion (or in CLC++
    for that matter). And Joona is exceptionally tolerant, even of idiots.

    --
    Mark McIntyre
    CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
    CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>


    ----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
    http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
    ---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
     
    Mark McIntyre, Jan 24, 2004
    #19
  20. On Sat, 24 Jan 2004 11:27:01 +0100, in comp.lang.c , Rolf Magnus
    <> wrote:

    >Martin Dickopp wrote:
    >
    >> 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?


    There's a difference between the two meanings of "stack".


    --
    Mark McIntyre
    CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
    CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>


    ----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
    http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
    ---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
     
    Mark McIntyre, Jan 24, 2004
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. GG
    Replies:
    4
    Views:
    570
  2. MSG

    Heap vs Stack allocations

    MSG, Jan 22, 2004, in forum: C Programming
    Replies:
    19
    Views:
    715
    Rob Thorpe
    Jan 29, 2004
  3. Michal Slocinski

    Heap dump file size vs heap size

    Michal Slocinski, Mar 25, 2008, in forum: Java
    Replies:
    1
    Views:
    772
    GArlington
    Mar 25, 2008
  4. viki
    Replies:
    6
    Views:
    627
    Erik Wikström
    Jun 28, 2008
  5. Raymond Schanks
    Replies:
    0
    Views:
    594
    Raymond Schanks
    Apr 11, 2010
Loading...

Share This Page