int a, int b[a]

[Kev]

If I understand correctly, this should not work:

int a;
int b[a];

An SDK file I am checking out uses this in 3 or 4 structs. It does say its
written in C style. If that makes a difference.

Also is this right? The read() function in <fstream.h> uses an unsigned
char. But <fstream> uses char?

[Kev]

Kev <di**************@pht.zzz> wrote in
news:Xn**********************@216.168.3.44:

If I understand correctly, this should not work:

int a;
int b[a];

An SDK file I am checking out uses this in 3 or 4 structs. It does say
its written in C style. If that makes a difference.

Note: seems for the first part those particular structs (its in a spec file
btw) are more for what information they should contain. Not so much how to
make them work. Eg: finding a, then using new to create b.

[msalters]

Kev schreef:

The read() function in <fstream.h> uses an unsigned char.
But <fstream> uses char?

fstream.h is not a standard header. It can contain anything. Typically
it's included by compilers to provide support for pre-standard programs
(i.e. before 1998). Since it's pre-standard, we can't say anything
sensible about what's in it.

HTH,
Michiel Salters

[Havatcha]

Kev wrote:

If I understand correctly, this should not work:

int a;
int b[a];
AFAIK, that is a memory allocation fault waiting to happen.
An SDK file I am checking out uses this in 3 or 4 structs. It does say its
written in C style. If that makes a difference.

There may be some deeper cleverness in the structs themselves, but from
the code posted it looks like an error.

Also is this right? The read() function in <fstream.h> uses an unsigned
char. But <fstream> uses char?

[peter.koch.larsen]

Kev wrote:

If I understand correctly, this should not work:

int a;
int b[a];
You are correct - this does not work.
An SDK file I am checking out uses this in 3 or 4 structs. It does say its
written in C style. If that makes a difference.
Okay. "C style" implies that it is not C. I doubt any C/C++-compiler
supports that syntax - even as an extension. It is not C and not C++.
C99 does support a syntax like that (so far as I know - I'm not a C99
expert), but only as part of a function-local parameter.

Also is this right? The read() function in <fstream.h> uses an unsigned
char. But <fstream> uses char?

Could be. I don't know fstream.

/Peter

[benben]

> Kev wrote:

If I understand correctly, this should not work:

int a;
int b[a];

AFAIK, that is a memory allocation fault waiting to happen.

No, it is not. I don't see a chance the code gets compiled.

[Abhi]

This should fail compilation for both C and C++
-Abhi

[Howard]

"Kev" <di**************@pht.zzz> wrote in message
news:Xn**********************@216.168.3.44...

If I understand correctly, this should not work:

int a;
int b[a];

An SDK file I am checking out uses this in 3 or 4 structs. It does say its
written in C style. If that makes a difference.

What does it _really_ look like? The above can't possibly compile, for two
reasons. First, the size of the array has to be a compile-time constant,
not a variable. Second, the code you've shown doesn't even initialize a to
anything, so there's no way in the world for the compiler to know how big to
make the array, even if it were _allowed_ to use plain int variables for the
array size.

Perhaps that was more like this?

const int a = 3;
int b[a];

?

-Howard

[Sudarshan Raghunathan]

AFAIK, variable length arrays are supported by C99. I've used similar
constuctions and they compile (with recent gcc versions) and run just
fine. E.g., the following program does exactly what it should (gcc
3.2.3). Surprised? So was I when I first saw it work. Is this a good
idea for a cross platform code? Probably not - haven't tested it yet
with other compilers.

#include <iostream>
using namespace std;

int main(void)
{
unsigned int a;
cin >> a;

int b[a];

for (int i = 0; i < a; i++)
b[i] = i;

for (int i = 0; i < a; i++)
cerr << b[i] << endl;

}

[Puppet_Sock]

Sudarshan Raghunathan wrote:

AFAIK, variable length arrays are supported by C99. I've used similar
constuctions and they compile (with recent gcc versions) and run just
fine. E.g., the following program does exactly what it should (gcc
3.2.3). Surprised? So was I when I first saw it work. Is this a good
idea for a cross platform code? Probably not - haven't tested it yet
with other compilers.

#include <iostream>
using namespace std;
Above you mentioned C99, but here you are using C++ stuff.
int main(void)
{
unsigned int a;
cin >> a;

int b[a];
Won't compile. Needs a compile-time constant expression.
for (int i = 0; i < a; i++)
b[i] = i;
Signed/unsigned mismatch warning.
for (int i = 0; i < a; i++)
cerr << b[i] << endl;

Signed/unsigned mismatch warning.
Socks

[Howard]

"Sudarshan Raghunathan" <rd******@gmail.com> wrote in message
news:11**********************@g49g2000cwa.googlegr oups.com...

AFAIK, variable length arrays are supported by C99. I've used similar
constuctions and they compile (with recent gcc versions) and run just
fine. E.g., the following program does exactly what it should (gcc
3.2.3). Surprised? So was I when I first saw it work. Is this a good
idea for a cross platform code? Probably not - haven't tested it yet
with other compilers.

#include <iostream>
using namespace std;

int main(void)
{
unsigned int a;
cin >> a;

int b[a];

In C++, the array size _must_ be a compile-time constant. If you're
compiling as a C++ program, and your compiler allows this, then it's either
a non-standard extension provided by that compiler, or a non-standard
compiler.

-Howard

[Sudarshan Raghunathan]

I suspect it is the former (non-standard extension provided by gcc)
rather than the latter (I'm not using an obscure C++ compiler on an
obscure platform). My only point was that you can get away with such
constructs with certain versions of gcc -nothing else.

[xuatla]

Howard wrote:

"Sudarshan Raghunathan" <rd******@gmail.com> wrote in message
news:11**********************@g49g2000cwa.googlegr oups.com...

AFAIK, variable length arrays are supported by C99. I've used similar
constuctions and they compile (with recent gcc versions) and run just
fine. E.g., the following program does exactly what it should (gcc
3.2.3). Surprised? So was I when I first saw it work. Is this a good
idea for a cross platform code? Probably not - haven't tested it yet
with other compilers.

#include <iostream>
using namespace std;

int main(void)
{
unsigned int a;
cin >> a;

int b[a];

In C++, the array size _must_ be a compile-time constant. If you're
compiling as a C++ program, and your compiler allows this, then it's either
a non-standard extension provided by that compiler, or a non-standard
compiler.

-Howard

o, amazing. I copied that code and compile. It really went through
successfully! I couldn't believe it but you may try it too. I am using
gcc 3.3.3.
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --disable-libunwind-exceptions --with-system-zlib
--enable-__cxa_atexit --host=i386-redhat-linux
Thread model: posix
gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7)

-X

[Sudarshan Raghunathan]

Oh, and here's some documentation too (just search for variable length
arrays):
http://developer.apple.com/documenta...le-Length.html

[Kev]

"Howard" <al*****@hotmail.com> wrote in
news:Pi*******************@bgtnsc04-news.ops.worldnet.att.net:

What does it _really_ look like? The above can't possibly compile,
for two reasons. First, the size of the array has to be a
compile-time constant, not a variable. Second, the code you've shown
doesn't even initialize a to anything, so there's no way in the world
for the compiler to know how big to make the array, even if it were
_allowed_ to use plain int variables for the array size.

Perhaps that was more like this?

const int a = 3;
int b[a];

Quite right. It doesnt compile. Really I didnt expect it to. But it did
make me wonder its even there. It was suggested to me last evening that its
merely to show what information in contains, not how to use it. And that in
this case 'triangleIndices[]' must be allocated dynamically. So I suppose I
was misinterpreting what it was.

Its from the Milkshape 3D specfile btw. Arrays in the others are declared
the usual way. "myarray[10]".

typedef struct
{
byte flags;
char name[32];
word numtriangles;
word triangleIndices[numtriangles];
char materialIndex;
} ms3d_group_t;

[Howard]

"Kev" <di**************@pht.zzz> wrote in message

typedef struct
{
byte flags;
char name[32];
word numtriangles;
word triangleIndices[numtriangles];
char materialIndex;
} ms3d_group_t;

I think that you're looking at a C example, not a C++ example. That form of
declaring a struct via a typedef statement indicates to me that this is C
code. It's not legal C++, even if some compiler does accept it.

I can't personally verify one way or the other if it's legal in C, though.

(By the way, in C++, I'd prefer to use std::vector over a raw array,
whenever possible.)

-Howard

[Kev]

"Howard" <al*****@hotmail.com> wrote in
news:Uv*******************@bgtnsc04-news.ops.worldnet.att.net:

I think that you're looking at a C example, not a C++ example. That
form of declaring a struct via a typedef statement indicates to me
that this is C code. It's not legal C++, even if some compiler does
accept it.

Yes it says its written in C style.

[Old Wolf]

xuatla wrote:

"Sudarshan Raghunathan" <rd******@gmail.com> wrote:

#include <iostream>
using namespace std;

int main(void)
{
unsigned int a;
cin >> a;

int b[a];

o, amazing. I copied that code and compile. It really went through
successfully! I couldn't believe it but you may try it too. I am using
gcc 3.3.3.

GCC will give an error iff you specify the -pedantic switch.
In fact, for checking that your code conforms to ISO C++, you
should compile with at least these switches:

g++ -Wall -Wextra -ansi -pedantic