memory allocation for local variables

[Rahul]

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

 

[ltcmelo]

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

 

[Martin York]

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

 

[ciccio]

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

 

[Ian Collins]

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.

 

[James Kanze]

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.

 

[Erik Wikström]

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.

 

[John Brawley]

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.

 

[Default User]

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

 

[John Brawley]

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.

 

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

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

 

[John Brawley]

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

 

[Jeff Schwab]

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.

 

[John Brawley]

John Brawley 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. 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?

 

[Ian Collins]

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

 

[John Brawley]

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

 

[James Kanze]

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.

 

[John Brawley]

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.

 

[terminator]

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]

 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.