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:03am, 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:james.kanze@gmail.com
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-news@hotmail.com> wrote in message
news:613plqF1rf19cU2@mid.individual.net...
> 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" <defaultuserbr@yahoo.com> wrote in message
news:61481mF1t119gU1@mid.individual.net...
> 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 wrote:
> "Default User" <defaultuserbr@yahoo.com> wrote in message
> news:61481mF1t119gU1@mid.individual.net...
>> 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" <ian-news@hotmail.com> wrote in message
news:6149oaF1rf19cU13@mid.individual.net...
> John Brawley wrote:
> > "Default User" <defaultuserbr@yahoo.com> wrote in message
> > news:61481mF1t119gU1@mid.individual.net...
> >> 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 wrote:
> "Ian Collins" <ian-news@hotmail.com> wrote in message
> news:6149oaF1rf19cU13@mid.individual.net...
>> John Brawley wrote:
>>> "Default User" <defaultuserbr@yahoo.com> wrote in message
>>> news:61481mF1t119gU1@mid.individual.net...
>>>> 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" <jeff@schwabcenter.com> wrote in message
news:P6adnRFvDNSaazHanZ2dnUVZ_vCknZ2d@comcast.com. ..
> John Brawley wrote:
> > "Ian Collins" <ian-news@hotmail.com> wrote in message
> > news:6149oaF1rf19cU13@mid.individual.net...
> >> John Brawley wrote:
> >>> "Default User" <defaultuserbr@yahoo.com> wrote in message
> >>> news:61481mF1t119gU1@mid.individual.net...
> >>>> 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 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" <ian-news@hotmail.com> wrote in message
news:614da8F1rf19cU14@mid.individual.net...
> 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

On Feb 9, 12:48 am, "Default User" <defaultuse...@yahoo.com> 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:james.kanze@gmail.com
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" <james.kanze@gmail.com> wrote in message
news:1e7b5ded-3a08-4744-896d-7e6cfbd26511@v46g2000hsv.googlegroups.com...
On Feb 9, 12:48 am, "Default User" <defaultuse...@yahoo.com> 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
jb@tetrahedraverse.com
Web: http://tetrahedraverse.com

On Feb 9, 9:31pm, James Kanze <james.ka...@gmail.com> wrote:
> On Feb 9, 12:48 am, "Default User" <defaultuse...@yahoo.com> 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

On Feb 9, 9:31pm, James Kanze <james.ka...@gmail.com> 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.

On Feb 11, 4:10 pm, terminator <farid.mehr...@gmail.com> wrote:
> On Feb 9, 9:31 pm, James Kanze <james.ka...@gmail.com> 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?

Of course. And that wouldn't be the syntax.

In context, the * is really just a typo---what I was thinking
about was:

int* pArray = new int[ size ] ;

Something like
int& rFirst = *new int[ size ] ;
// ...
delete [] &rFirst ;
is also legal, but not very useful, since the only way to access
beyond the first element is to take the address of rFirst, and
then do pointer arithmetic on it.

Something like:

int (&array)[ size ]
= reinterpret_cast< int(&)[ size ] >( *new int[ size ] ) ;
// ...
delete [] &array ;

is also legal, if size is a constant, but frankly, I wouldn't
recommend it.

When all is said and done, of course, if you are allocating
arrays dynamically, and their lifetime corresponds to some sort
of scope, there is absolutely no reason not to use std::vector.
If the lifetime is truely dynamic, then you can usually use
std::vector as well, but there will be cases where it will
introduce an additional indirection.

> I used to think that new was used for pointer to arrays.

You mean that new of an array returns a pointer to the first
element, and not a pointer to the array. That's true (except
that the first element is guaranteed to have the same address as
the array, so my reinterpret_cast above works).

--
James Kanze (GABI Software) email:james.kanze@gmail.com
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 Feb 12, 11:56am, James Kanze <james.ka...@gmail.com> wrote:
> On Feb 11, 4:10 pm, terminator <farid.mehr...@gmail.com> wrote:
>
> > On Feb 9, 9:31 pm, James Kanze <james.ka...@gmail.com> 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?
>
> Of course. And that wouldn't be the syntax.
>
> In context, the * is really just a typo---what I was thinking
> about was:
>
> int* pArray = new int[ size ] ;
>
> Something like
> int& rFirst = *new int[ size ] ;
> // ...
> delete [] &rFirst ;
> is also legal, but not very useful, since the only way to access
> beyond the first element is to take the address of rFirst, and
> then do pointer arithmetic on it.
>

that is what i am used to accept.

> Something like:
>
> int (&array)[ size ]
> = reinterpret_cast< int(&)[ size ] >( *new int[ size ] );
> // ...
> delete [] &array ;
>
> is also legal, if size is a constant, but frankly, I wouldn't
> recommend it.
>

nor do many.

> When all is said and done, of course, if you are allocating
> arrays dynamically, and their lifetime corresponds to some sort
> of scope, there is absolutely no reason not to use std::vector.
> If the lifetime is truely dynamic, then you can usually use
> std::vector as well, but there will be cases where it will
> introduce an additional indirection.
>
> > I used to think that new was used for pointer to arrays.
>
> You mean that new of an array returns a pointer to the first
> element, and not a pointer to the array. That's true (except
> that the first element is guaranteed to have the same address as
> the array, so my reinterpret_cast above works).
>
yes.

thanks,
FM.

In message <I5nrj.73$WF1.64@newsfe06.lga>, John Brawley
<jgbrawley@charter.net> writes
>
>"James Kanze" <james.kanze@gmail.com> wrote in message
>news:1e7b5ded-3a08-4744-896d-7e6cfbd26511@v46g2000hsv.googlegroups.com...
>On Feb 9, 12:48 am, "Default User" <defaultuse...@yahoo.com> 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.
>
Nobody seems to have posted the obvious (FAQ) response to clarify the
alleged confusion. Namely:

"Please post an example of minimal, complete, compileable code that
illustrates what you are trying to do."

http://www.parashift.com/c++-faq-lit...t.html#faq-5.8

--
Richard Herring