«

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

On Feb 8, 10:03*am, Rahul <sam_...@yahoo.co.in> 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

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

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

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.

On Feb 8, 2:03 pm, Rahul <sam_...@yahoo.co.in> 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

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

"Ian Collins" <ian-> 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 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" <> 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