Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > memory allocation for local variables

Reply
Thread Tools

memory allocation for local variables

 
 
Rahul
Guest
Posts: n/a
 
      02-08-2008
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!!!
 
Reply With Quote
 
 
 
 
ltcmelo
Guest
Posts: n/a
 
      02-08-2008
On Feb 8, 10:03*am, Rahul <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
 
Martin York
Guest
Posts: n/a
 
      02-08-2008

>
> 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++.
 
Reply With Quote
 
ciccio
Guest
Posts: n/a
 
      02-08-2008
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
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      02-08-2008
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.
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      02-08-2008
On Feb 8, 2:03 pm, Rahul <(E-Mail Removed)> 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:(E-Mail Removed)
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
 
Reply With Quote
 
Erik Wikström
Guest
Posts: n/a
 
      02-08-2008
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
 
Reply With Quote
 
John Brawley
Guest
Posts: n/a
 
      02-08-2008

"Ian Collins" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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




 
Reply With Quote
 
Default User
Guest
Posts: n/a
 
      02-08-2008
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
 
Reply With Quote
 
John Brawley
Guest
Posts: n/a
 
      02-09-2008

"Default User" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
memory allocation of local variables sandy C Programming 2 12-13-2006 03:46 PM
static memory allocation versus dynamic memory allocation Ken C Programming 24 11-30-2006 12:37 AM
What is the difference between dynamic memory allocation,and stack allocation ? chris C++ 6 10-28-2005 05:27 AM
allocation alignment for global and local variables. gamja C Programming 4 09-30-2005 10:42 PM
allocation of local variables on stack bahadir.balban@gmail.com C Programming 26 06-17-2005 09:49 PM



Advertisments