memory allocation for local variables

Discussion in 'C++' started by Rahul, Feb 8, 2008.

  1. Rahul

    Rahul Guest

    Hi Everyone,

    I have the following program unit,

    int main()
    {
    int size = 0;
    cout<<"please enter the size"<<endl;
    cin>>size;
    int array[size];
    }

    Now i'm assuming that the memory for array in the stack is allocated
    dynamically after the size is known from the user, [based on g++].
    Does the standard say anything about this? or is this implementation
    specific of the compilers?

    Thanks in advance!!!
     
    Rahul, Feb 8, 2008
    #1
    1. Advertising

  2. Rahul

    ltcmelo Guest

    On Feb 8, 10:03 am, Rahul <> wrote:
    > Hi Everyone,
    >
    >  I have the following program unit,
    >
    > int main()
    > {
    >  int size = 0;
    >  cout<<"please enter the size"<<endl;
    >  cin>>size;
    >  int array[size];
    >
    > }
    >
    >  Now i'm assuming that the memory for array in the stack is allocated
    > dynamically after the size is known from the user, [based on g++].
    > Does the standard say anything about this? or is this implementation
    > specific of the compilers?
    >
    > Thanks in advance!!!



    Hi.

    This is not standard C++ because size is not a compile time constant.
    However, I think this is legal C, according to the 99 standard.
    Anyway, it's probably allocated in the free storage (heap).


    Leandro Melo
     
    ltcmelo, Feb 8, 2008
    #2
    1. Advertising

  3. Rahul

    Martin York Guest


    >
    > Now i'm assuming that the memory for array in the stack is allocated
    > dynamically after the size is known from the user,



    Does it matter where the momry physically is?

    All that matters is that it does not leak.
    The compiler will guarantee that. But not standard C++.
     
    Martin York, Feb 8, 2008
    #3
  4. Rahul

    ciccio Guest

    Hi
    > I have the following program unit,
    >
    > int main()
    > {
    > int size = 0;
    > cout<<"please enter the size"<<endl;
    > cin>>size;
    > int array[size];
    > }
    >
    > Now i'm assuming that the memory for array in the stack is allocated
    > dynamically after the size is known from the user, [based on g++].
    > Does the standard say anything about this? or is this implementation
    > specific of the compilers?


    I did the following test with changing the stack size.
    It is clearly going to the stack.

    Regards


    [test]$ cat test.cpp
    #include <iostream>

    int main() {

    int size ;
    std::cout<< "please enter the size" << std::endl;
    std::cin>>size;
    std::cout << sizeof(int[size]) << std::endl;
    int array[size];
    array[0] = size;

    return 0;
    }
    [test]$ ulimit -a | grep stack
    stack size (kbytes, -s) 8192
    [test]$ echo 2093442 | ./a.out
    please enter the size
    8373768
    [test]$ echo 2093443 | ./a.out
    please enter the size
    8373772
    Segmentation fault
    [test]$ ulimit -s 4000
    [test]$ ulimit -a | grep stack
    stack size (kbytes, -s) 4000
    [test]$ echo 2093442 | ./a.out
    please enter the size
    8373768
    Segmentation fault
    [test]$ echo 2093441 | ./a.out
    please enter the size
    8373764
    Segmentation fault
    [test]$ echo 1093441 | ./a.out
    please enter the size
    [test]$ echo 1020000 | ./a.out
    please enter the size
    4080000
    [test]$ echo 1024000 | ./a.out
    please enter the size
    4096000
    Segmentation fault
     
    ciccio, Feb 8, 2008
    #4
  5. Rahul

    Ian Collins Guest

    Rahul wrote:
    > Hi Everyone,
    >
    > I have the following program unit,
    >
    > int main()
    > {
    > int size = 0;
    > cout<<"please enter the size"<<endl;
    > cin>>size;
    > int array[size];


    This is a gcc extension, so if you want the gory details, try a gcc group.

    --
    Ian Collins.
     
    Ian Collins, Feb 8, 2008
    #5
  6. Rahul

    James Kanze Guest

    On Feb 8, 2:03 pm, Rahul <> wrote:
    > I have the following program unit,


    > int main()
    > {
    > int size = 0;
    > cout<<"please enter the size"<<endl;
    > cin>>size;
    > int array[size];
    > }


    > Now i'm assuming that the memory for array in the stack is allocated
    > dynamically after the size is known from the user, [based on g++].


    It's better to assume that this won't compile with a C++
    compiler. g++ complains if you invoke it with -std=c++98
    -pendantic.

    It is legal C (if you replace the iostream stuff with stdio, of
    course).

    > Does the standard say anything about this? or is this implementation
    > specific of the compilers?


    No more than it says anything about how other local variables
    are allocated. Typically, however, the compiler will generate
    code to increase the stack size by an appropriate amount once it
    knows the size of the array. This isn't necessarily possible,
    however, and some implementations will probably allocate the
    space on the heap, and generate code to automatically delete it
    when the variable goes out of scope. (FWIW: I once used a C
    compiler that allocated *all* local variables this way.)

    Try googling for alloca. That's where the motivation for
    support for this originally came from.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Feb 8, 2008
    #6
  7. On 2008-02-08 19:30, ciccio wrote:
    > Hi
    >> I have the following program unit,
    >>
    >> int main()
    >> {
    >> int size = 0;
    >> cout<<"please enter the size"<<endl;
    >> cin>>size;
    >> int array[size];
    >> }
    >>
    >> Now i'm assuming that the memory for array in the stack is allocated
    >> dynamically after the size is known from the user, [based on g++].
    >> Does the standard say anything about this? or is this implementation
    >> specific of the compilers?

    >
    > I did the following test with changing the stack size.
    > It is clearly going to the stack.
    >
    > Regards
    >
    >
    > [test]$ cat test.cpp
    > #include <iostream>
    >
    > int main() {
    >
    > int size ;
    > std::cout<< "please enter the size" << std::endl;
    > std::cin>>size;
    > std::cout << sizeof(int[size]) << std::endl;
    > int array[size];
    > array[0] = size;
    >
    > return 0;
    > }


    Or you could have simply printed out the addresses of the array and a
    variable that you know is on the stack. However where the data is stored
    is not specified in the standard so you can not make any use of such
    information without making the code very platform and compiler
    dependent. An implementation where the array was malloced on the stack
    and calls to free were inserted at appropriate places would also work.

    --
    Erik Wikström
     
    Erik Wikström, Feb 8, 2008
    #7
  8. Rahul

    John Brawley Guest

    "Ian Collins" <> wrote in message
    news:...
    > Rahul wrote:
    > > Hi Everyone,
    > >
    > > I have the following program unit,
    > >
    > > int main()
    > > {
    > > int size = 0;
    > > cout<<"please enter the size"<<endl;
    > > cin>>size;
    > > int array[size];

    >
    > This is a gcc extension, so if you want the gory details, try a gcc group.
    > Ian Collins.


    I don't know if this is the same idea, but I do _exactly_ this with an
    array[].
    My program can't grab the necessary memory until the user enters a number so
    the program can provide it for what comes later.
    I was told the only two ways to do this were an array[] and a vector[], and
    I had to create the array[] with *new.


    --
    Peace
    JB
     
    John Brawley, Feb 8, 2008
    #8
  9. Rahul

    Default User Guest

    John Brawley wrote:

    > I don't know if this is the same idea, but I do exactly this with an
    > array[].
    > My program can't grab the necessary memory until the user enters a
    > number so the program can provide it for what comes later.
    > I was told the only two ways to do this were an array[] and a
    > vector[], and I had to create the array[] with *new.


    It's an extension. It's not standard, and so it is not portable. If you
    use it in g++, it may not work with another compiler. It won't work if
    instruct g++ to adhere to standards.

    In C, there is now a construct called "variable length arrays". Those
    are not part of C++. The only portable way to do it is with std::vector
    (and you should have really good reasons for not using that in the
    first place) and a pointer with new.



    Brian
     
    Default User, Feb 8, 2008
    #9
  10. Rahul

    John Brawley Guest

    "Default User" <> wrote in message
    news:...
    > John Brawley wrote:
    >
    > > I don't know if this is the same idea, but I do exactly this with an
    > > array[].
    > > My program can't grab the necessary memory until the user enters a
    > > number so the program can provide it for what comes later.
    > > I was told the only two ways to do this were an array[] and a
    > > vector[], and I had to create the array[] with *new.

    >
    > It's an extension. It's not standard, and so it is not portable. If you
    > use it in g++, it may not work with another compiler. It won't work if
    > instruct g++ to adhere to standards.
    >
    > In C, there is now a construct called "variable length arrays". Those
    > are not part of C++. The only portable way to do it is with std::vector
    > (and you should have really good reasons for not using that in the
    > first place) and a pointer with new.
    > Brian


    (!) I did not know it was nonstandard, nor that it would be nonportable.
    The question arises though: _how_ nonportable? The machines this program
    has run on all run it perfectly, but they were probably all Windows machines
    (it ran on 95, 98(mine), and XP, and ported with minor mods not including
    replacing the *new array[], to Linux, so I'm not sure how dangerous my *new
    array[] really is.... Is there some way for me to tell how nonportable I've
    made this thing?, besides the various people and machines it ran on?
    (My reasons for not using vectors were 1) I didn't understand how at the
    time and b) I read that if you resize a vector downward it's possible to
    "lose" pointers' ties into it, and c) the original was written in Python
    (this C++ is a translation), which itself wears C underpants, and I was
    familiar with Python's "lists{}"' and "dictionaries[]"' identical
    accessing-and-storing syntax.
    Perhaps if I rewrite it again (only for _speed_, only for _speed_ (*g*)),
    I'll try it with vectors.


    --
    Peace
    JB
     
    John Brawley, Feb 9, 2008
    #10
  11. Rahul

    Ian Collins Guest

    John Brawley wrote:
    > "Default User" <> wrote in message
    > news:...
    >> John Brawley wrote:
    >>
    >>> I don't know if this is the same idea, but I do exactly this with an
    >>> array[].
    >>> My program can't grab the necessary memory until the user enters a
    >>> number so the program can provide it for what comes later.
    >>> I was told the only two ways to do this were an array[] and a
    >>> vector[], and I had to create the array[] with *new.

    >> It's an extension. It's not standard, and so it is not portable. If you
    >> use it in g++, it may not work with another compiler. It won't work if
    >> instruct g++ to adhere to standards.
    >>
    >> In C, there is now a construct called "variable length arrays". Those
    >> are not part of C++. The only portable way to do it is with std::vector
    >> (and you should have really good reasons for not using that in the
    >> first place) and a pointer with new.
    >> Brian

    >
    > (!) I did not know it was nonstandard, nor that it would be nonportable.
    > The question arises though: _how_ nonportable? The machines this program
    > has run on all run it perfectly, but they were probably all Windows machines
    > (it ran on 95, 98(mine), and XP, and ported with minor mods not including
    > replacing the *new array[], to Linux, so I'm not sure how dangerous my *new
    > array[] really is.... Is there some way for me to tell how nonportable I've
    > made this thing?, besides the various people and machines it ran on?


    It's portable to anywhere were the compiler you compiled it with has a
    port...

    --
    Ian Collins.
     
    Ian Collins, Feb 9, 2008
    #11
  12. Rahul

    John Brawley Guest

    "Ian Collins" <> wrote in message
    news:...
    > John Brawley wrote:
    > > "Default User" <> wrote in message
    > > news:...
    > >> John Brawley wrote:
    > >>
    > >>> I don't know if this is the same idea, but I do exactly this with an
    > >>> array[].
    > >>> My program can't grab the necessary memory until the user enters a
    > >>> number so the program can provide it for what comes later.
    > >>> I was told the only two ways to do this were an array[] and a
    > >>> vector[], and I had to create the array[] with *new.
    > >> It's an extension. It's not standard, and so it is not portable. If you
    > >> use it in g++, it may not work with another compiler. It won't work if
    > >> instruct g++ to adhere to standards.
    > >>
    > >> In C, there is now a construct called "variable length arrays". Those
    > >> are not part of C++. The only portable way to do it is with std::vector
    > >> (and you should have really good reasons for not using that in the
    > >> first place) and a pointer with new.
    > >> Brian

    > >
    > > (!) I did not know it was nonstandard, nor that it would be nonportable.
    > > The question arises though: _how_ nonportable? The machines this

    program
    > > has run on all run it perfectly, but they were probably all Windows

    machines
    > > (it ran on 95, 98(mine), and XP, and ported with minor mods not

    including
    > > replacing the *new array[], to Linux, so I'm not sure how dangerous my

    *new
    > > array[] really is.... Is there some way for me to tell how nonportable

    I've
    > > made this thing?, besides the various people and machines it ran on?

    >
    > It's portable to anywhere were the compiler you compiled it with has a
    > port...
    > Ian Collins.


    Uh... please pardon: I don't follow....
    Compiler: Borland command line tools v5.5 (BCC32).
    How, pray tell, does somewhere else have a "port" specific to a compiler?
    (Pardon also: I have a sneakin' suspicion that was humor, but I'm not
    sure....)


    --
    Peace
    JB
     
    John Brawley, Feb 9, 2008
    #12
  13. Rahul

    Jeff Schwab Guest

    John Brawley wrote:
    > "Ian Collins" <> wrote in message
    > news:...
    >> John Brawley wrote:
    >>> "Default User" <> wrote in message
    >>> news:...
    >>>> John Brawley wrote:
    >>>>
    >>>>> I don't know if this is the same idea, but I do exactly this with an
    >>>>> array[].
    >>>>> My program can't grab the necessary memory until the user enters a
    >>>>> number so the program can provide it for what comes later.
    >>>>> I was told the only two ways to do this were an array[] and a
    >>>>> vector[], and I had to create the array[] with *new.
    >>>> It's an extension. It's not standard, and so it is not portable. If you
    >>>> use it in g++, it may not work with another compiler. It won't work if
    >>>> instruct g++ to adhere to standards.
    >>>>
    >>>> In C, there is now a construct called "variable length arrays". Those
    >>>> are not part of C++. The only portable way to do it is with std::vector
    >>>> (and you should have really good reasons for not using that in the
    >>>> first place) and a pointer with new.
    >>>> Brian
    >>> (!) I did not know it was nonstandard, nor that it would be nonportable.
    >>> The question arises though: _how_ nonportable? The machines this

    > program
    >>> has run on all run it perfectly, but they were probably all Windows

    > machines
    >>> (it ran on 95, 98(mine), and XP, and ported with minor mods not

    > including
    >>> replacing the *new array[], to Linux, so I'm not sure how dangerous my

    > *new
    >>> array[] really is.... Is there some way for me to tell how nonportable

    > I've
    >>> made this thing?, besides the various people and machines it ran on?

    >> It's portable to anywhere were the compiler you compiled it with has a
    >> port...
    >> Ian Collins.

    >
    > Uh... please pardon: I don't follow....
    > Compiler: Borland command line tools v5.5 (BCC32).
    > How, pray tell, does somewhere else have a "port" specific to a compiler?
    > (Pardon also: I have a sneakin' suspicion that was humor, but I'm not
    > sure....)


    The language extension you're using is a feature of the compiler, not
    the platform. If you run the same compiler on a different platform, the
    behavior will generally be the same as on the first platform.
    Similarly, if you use a compiler that takes a stricter view of
    variable-length arrays, it should give you the same diagnostic on any
    platform to which it has been ported.

    If Borland v5.5 was written for Windows 95, but runs on Linux, then it
    is said to have been "ported" to Linux, or to have a "port" on Linux.
    If it has been officially ported to BSD, then it will exist in the BSD
    "ports" tree. If it has been formally ported to Gentoo, then it will
    exist in a system called "portage." GCC was not originally written for
    Windows, but does have a port to it.
     
    Jeff Schwab, Feb 9, 2008
    #13
  14. Rahul

    John Brawley Guest

    "Jeff Schwab" <> wrote in message
    news:p...
    > John Brawley wrote:
    > > "Ian Collins" <> wrote in message
    > > news:...
    > >> John Brawley wrote:
    > >>> "Default User" <> wrote in message
    > >>> news:...
    > >>>> John Brawley wrote:
    > >>>>
    > >>>>> I don't know if this is the same idea, but I do exactly this with an
    > >>>>> array[].
    > >>>>> My program can't grab the necessary memory until the user enters a
    > >>>>> number so the program can provide it for what comes later.
    > >>>>> I was told the only two ways to do this were an array[] and a
    > >>>>> vector[], and I had to create the array[] with *new.
    > >>>> It's an extension. It's not standard, and so it is not portable. If

    you
    > >>>> use it in g++, it may not work with another compiler. It won't work

    if
    > >>>> instruct g++ to adhere to standards.
    > >>>>
    > >>>> In C, there is now a construct called "variable length arrays". Those
    > >>>> are not part of C++. The only portable way to do it is with

    std::vector
    > >>>> (and you should have really good reasons for not using that in the
    > >>>> first place) and a pointer with new.
    > >>>> Brian
    > >>> (!) I did not know it was nonstandard, nor that it would be

    nonportable.
    > >>> The question arises though: _how_ nonportable? The machines this

    > > program
    > >>> has run on all run it perfectly, but they were probably all Windows

    > > machines
    > >>> (it ran on 95, 98(mine), and XP, and ported with minor mods not

    > > including
    > >>> replacing the *new array[], to Linux, so I'm not sure how dangerous my

    > > *new
    > >>> array[] really is.... Is there some way for me to tell how

    nonportable
    > > I've
    > >>> made this thing?, besides the various people and machines it ran on?
    > >> It's portable to anywhere were the compiler you compiled it with has a
    > >> port...
    > >> Ian Collins.

    > >
    > > Uh... please pardon: I don't follow....
    > > Compiler: Borland command line tools v5.5 (BCC32).
    > > How, pray tell, does somewhere else have a "port" specific to a

    compiler?
    > > (Pardon also: I have a sneakin' suspicion that was humor, but I'm not
    > > sure....)

    >
    > The language extension you're using is a feature of the compiler, not
    > the platform. If you run the same compiler on a different platform, the
    > behavior will generally be the same as on the first platform.
    > Similarly, if you use a compiler that takes a stricter view of
    > variable-length arrays, it should give you the same diagnostic on any
    > platform to which it has been ported.
    >
    > If Borland v5.5 was written for Windows 95, but runs on Linux, then it
    > is said to have been "ported" to Linux, or to have a "port" on Linux.
    > If it has been officially ported to BSD, then it will exist in the BSD
    > "ports" tree. If it has been formally ported to Gentoo, then it will
    > exist in a system called "portage." GCC was not originally written for
    > Windows, but does have a port to it.


    Ah.
    OK, thank you very much.
    The .EXE file that the compiler creates isn't nonportable then, right?


    --
    Peace
    JB
     
    John Brawley, Feb 9, 2008
    #14
  15. Rahul

    Ian Collins Guest

    John Brawley wrote:
    >
    > Ah.
    > OK, thank you very much.
    > The .EXE file that the compiler creates isn't nonportable then, right?
    >

    It certainly is. An executable generally will only run on the target
    platform. Compilers may be ported to several platforms, but each port
    will only generate code for the platform it is running on (unless it's a
    cross-compiler, but that's another story!).

    --
    Ian Collins.
     
    Ian Collins, Feb 9, 2008
    #15
  16. Rahul

    John Brawley Guest

    "Ian Collins" <> wrote in message
    news:...
    > John Brawley wrote:
    > >
    > > Ah.
    > > OK, thank you very much.
    > > The .EXE file that the compiler creates isn't nonportable then, right?
    > >

    > It certainly is. An executable generally will only run on the target
    > platform. Compilers may be ported to several platforms, but each port
    > will only generate code for the platform it is running on (unless it's a
    > cross-compiler, but that's another story!).
    > Ian Collins.


    Ok, thanks Ian.
    I'll study std::vector, then.
    I appreciate the advice and explanations.
    (From all, as well as you.)


    --
    Peace
    JB
     
    John Brawley, Feb 9, 2008
    #16
  17. Rahul

    James Kanze Guest

    On Feb 9, 12:48 am, "Default User" <> wrote:
    > John Brawley wrote:
    > > I don't know if this is the same idea, but I do exactly this
    > > with an array[]. My program can't grab the necessary memory
    > > until the user enters a number so the program can provide it
    > > for what comes later. I was told the only two ways to do
    > > this were an array[] and a vector[], and I had to create the
    > > array[] with *new.


    > It's an extension. It's not standard, and so it is not
    > portable.


    I think there's some confusion here. Variable length arrays in
    C++ are a g++ extension---as far as I know, no other C++ compiler
    implements them. Allocating array[] with *new is standard,
    however.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Feb 9, 2008
    #17
  18. Rahul

    John Brawley Guest

    "James Kanze" <> wrote in message
    news:...
    On Feb 9, 12:48 am, "Default User" <> wrote:
    > John Brawley wrote:
    > > I don't know if this is the same idea, but I do exactly this
    > > with an array[]. My program can't grab the necessary memory
    > > until the user enters a number so the program can provide it
    > > for what comes later. I was told the only two ways to do
    > > this were an array[] and a vector[], and I had to create the
    > > array[] with *new.


    > It's an extension. It's not standard, and so it is not
    > portable.


    I think there's some confusion here. Variable length arrays in
    C++ are a g++ extension---as far as I know, no other C++ compiler
    implements them. Allocating array[] with *new is standard,
    however.

    (*whew*)
    Thanks!
    Less worried, me.


    --
    Peace
    JB

    Web: http://tetrahedraverse.com
     
    John Brawley, Feb 9, 2008
    #18
  19. Rahul

    terminator Guest

    On Feb 9, 9:31 pm, James Kanze <> wrote:
    > On Feb 9, 12:48 am, "Default User" <> wrote:
    >
    > > John Brawley wrote:
    > > > I don't know if this is the same idea, but I do exactly this
    > > > with an array[].  My program can't grab the necessary memory
    > > > until the user enters a number so the program can provide it
    > > > for what comes later.  I was told the only two ways to do
    > > > this were an array[] and a vector[], and I had to create the
    > > > array[] with *new.

    > > It's an extension. It's not standard, and so it is not
    > > portable.

    >
    > I think there's some confusion here.  Variable length arrays in
    > C++ are a g++ extension---as far as I know, no other C++ compiler
    > implements them.  Allocating array[] with *new is standard,
    > however.
    > en informatique orientée objet/
    >                    Beratung in objektorientierter Datenverarbeitung
    > 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    terminator, Feb 11, 2008
    #19
  20. Rahul

    terminator Guest

    On Feb 9, 9:31 pm, James Kanze <> wrote:

    > Allocating array[] with *new is standard,


    I need more explanation plz.you mean like this?

    size_t sz;
    int array[]= * new int [sz];


    this looks odd to me !!!!!!!!!!so ,wont one have to delete the array
    explicitly?
    I used to think that new was used for pointer to arrays.
    plz describe it more.

    regards,
    FM.
     
    terminator, Feb 11, 2008
    #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. Replies:
    26
    Views:
    715
    Anonymous 7843
    Jun 17, 2005
  2. gamja
    Replies:
    4
    Views:
    313
    Christian Bau
    Sep 30, 2005
  3. Ken
    Replies:
    24
    Views:
    3,876
    Ben Bacarisse
    Nov 30, 2006
  4. sandy

    memory allocation of local variables

    sandy, Dec 13, 2006, in forum: C Programming
    Replies:
    2
    Views:
    383
    Stephen Sprunk
    Dec 13, 2006
  5. chris
    Replies:
    6
    Views:
    992
    chris
    Oct 28, 2005
Loading...

Share This Page