declaration of array with non-constant expression?

[mike.polyakov]

Hi Everyone,

I've just come across an expression that I always thought should not
compile:

int j = 0;
int b[j];

But it compiles fine under gcc4.3.4. Obviously it is not very useful,
but what does it mean? No memory can be allocated at compile time, but
b seems to act like a pointer. I've browsed through the standard and
found nothing that would indicate that this is legal. The section on
declarations of arrays (8.3.4) says that only constant expressions are
allowed in brackets. Can anyone please explain this to me?

Thank you.

-Mike

 

[Michael DOUBEZ]

Paavo Helde a écrit :

(e-mail address removed): [snip]

I've just come across an expression that I always thought should not
compile:

int j = 0;
int b[j];

But it compiles fine under gcc4.3.4. Obviously it is not very useful,

It is kind of useful since you only use the stack and not the heap to
allocate a table; it could be interesting in multithreaded application
to avoid synchronisation caused by allocation.

[snip]

This is a gcc extension. You can turn it off by some compiler option
( -std=c++98 IIRC).

It is a C99 standard feature called Variable Length Array (VLA).

 

[mike.polyakov]

Thank you for your replies!

This is definitely news to me So is this feature a part of official
C99 standard? Do you know if it is a part of C++ ISO standard 14882?

Also, I'd like to debate the usefulness of this. I just feel like
dynamic memory allocation should be more explicit - be it either
through alloc or malloc. I feel like slight typos will not be caught
by the compiler and there will be dynamic memory allocation for each
index somewhere deep inside a loop (this is why I asked this question
originally). Also, allocating large blocks of memory through alloc can
be dangerous because of the possibility of running off the stack. I
ran into having too small stack space before when using pthreads. The
issue can creep up unexpectedly when switching from 32bit to 64bit,
because stack size is specified in bytes and thus remains the same,
but word length doubles. I feel like using this shortcut syntax will
make it easier to create such problems.

Thanks.

-Mike

 

[Alf P. Steinbach]

* (e-mail address removed):

Thank you for your replies!

This is definitely news to me So is this feature a part of official
C99 standard?

VLAs are part of C99, yes.

Do you know if it is a part of C++ ISO standard 14882?

Happily C99 VLAs were not and will not be adopted in C++0x.

But unfortunately VLAs will not be adopted regardless of form.

That's apparently because most of the committee members (my judgement based on
discussions with three or four of them) are unable to understand that VLAs can
be implemented in more sane ways. It's sort of sad. They would be very very
useful, as is evidenced by today's type-unsafe 'alloca' (de facto standard),
that it's so much used and has propagated to so many compilers despite being
type-unsafe.

Also, I'd like to debate the usefulness of this.>

Very much extremely useful, but the C99 implementation of the concept is broken
in so many ways, it's so unbelievably dirty, that it has given a bad name to
VLAs -- and so the chances of getting something more sane in C++ are ~0. :-(


Cheers & hth.,

- Alf

 

[Michael DOUBEZ]

Alf P. Steinbach a écrit :

* (e-mail address removed):

VLAs are part of C99, yes.



Happily C99 VLAs were not and will not be adopted in C++0x.

But unfortunately VLAs will not be adopted regardless of form.

That's apparently because most of the committee members (my judgement
based on discussions with three or four of them) are unable to
understand that VLAs can be implemented in more sane ways. It's sort of
sad. They would be very very useful, as is evidenced by today's
type-unsafe 'alloca' (de facto standard), that it's so much used and has
propagated to so many compilers despite being type-unsafe.

IMVHO it wouldn't be trivial to specify it since the type would change
at runtime.

 

[Alf P. Steinbach]

* Michael DOUBEZ:

Alf P. Steinbach a écrit :

IMVHO it wouldn't be trivial to specify it since the type would change
at runtime.

Happily that's incorrect: the type doesn't have to change at runtime (that it
does in one of the abominations of C99 VLAs).

However, that doesn't mean that it's trivial to specify. It isn't trivial. But
that it isn't trivial doesn't mean that it's very difficult, either. The
difficulty of specification is simply not an issue. Not remarkable, not
relevant, except that core language support is required.

As mentioned, this has been discussed many times before.


Cheers & hth.,

- Alf

 

[Johannes Schaub (litb)]

* Michael DOUBEZ:

Happily that's incorrect: the type doesn't have to change at runtime (that
it does in one of the abominations of C99 VLAs).

However, that doesn't mean that it's trivial to specify. It isn't trivial.
But that it isn't trivial doesn't mean that it's very difficult, either.
The difficulty of specification is simply not an issue. Not remarkable,
not relevant, except that core language support is required.

As mentioned, this has been discussed many times before.

I think i heard something about a class called "dynarray<T>" that was
supposed to solve this issue. It's some kind of "static vector", that gets
its size at runtime and doesn't change its size during its lifetime. It's
allowed to use such techniques as alloca or something.

But i haven't heard about it anymore since quite some time now

 

[James Kanze]

Alf P. Steinbach a écrit :

IMVHO it wouldn't be trivial to specify it since the type
would change at runtime.

But is that a problem if only local variables could be VLAs?
(It's also a question of how you specify them; you could specify
a VLA type, for example, and then the type wouldn't change at
runtime.)

 

[Johannes Schaub (litb)]

But is that a problem if only local variables could be VLAs?
(It's also a question of how you specify them; you could specify
a VLA type, for example, and then the type wouldn't change at
runtime.)

C gets away with that by its concept of "compatible type", which is a
compile time concept, and delays determining of type identity to runtime
when a variably modified type is involved.

In C++, this could be done, i think, by the the concept of "dynamic type".
Specify that the static type of a VLA is int[*], and that the dynamic type
of an array is int[n], with n being determined at runtime.

As with inheritance, where when A is a base of B, there is a subobject of
type A in an object of type B, int[n-1] is a subobject of int[n].
dynamic_cast can be used to cast a int[*] to int[n], and when int[n] is not
a sub-object of the dynamic type of the array object, the runtime check
fails. This way, bounds checks can be done.

 

[Michael DOUBEZ]

Alf P. Steinbach a écrit :

* Michael DOUBEZ:

Happily that's incorrect: the type doesn't have to change at runtime
(that it does in one of the abominations of C99 VLAs).

Yes , I was thinking of C99 VLAs, I imagine that you would have to drop
the 'array with variable size' syntax.

However, that doesn't mean that it's trivial to specify. It isn't
trivial. But that it isn't trivial doesn't mean that it's very
difficult, either. The difficulty of specification is simply not an
issue. Not remarkable, not relevant, except that core language support
is required.

I imagined it made quite a number of issues: lives only on the stack,
check no stack overrun ... the c++ standard doesn't even mention the stack.

As mentioned, this has been discussed many times before.

OK. Got to google for it.