Perl Philosphy is simply to torment the implementors on behalf of the user -- Larry Wall
Look at the C99 rationale:
The inability to declare arrays whose size is known only at execution time was often cited as a primary deterrent to using C as a numerical computing language.
That's also the main reason for the introduction of complex types and type-generic math functions.
It's not as if the C committee got together and thought "Hey, what can we do to piss off compiler writers?" - there was actual demand for these features!
Sure, it made language semantics messier (runtime evaluation of sizeof, introduction of variably-modified types restricted to block or prototype scope, magical macros for math functions - which has been fixed with C11, btw), but C99 is indeed a superior language than C90 for doing numerics.
I don't dispute for a moment that some people wanted VLAs or that they're useful in some contexts. On the other hand, your cited field is relatively small, and the use case could have been satisfied with a mechanism much more in line with the existing language.
In fact, we've de-facto had such a mechanism for decades, but it hasn't been codified anywhere, actually for some of the same reasons people don't appreciate VLAs, but it at least rests much more comfortably with the rest of the language.
At some point, you go from enhancing C to breaking it in the interests of a small minority (who apparently don't want to use Fortran?). VLAs are, if not over the line, right on it.
// C99
double trace(size_t n, double mat[][n])
{
double sum = 0;
for(size_t i = 0; i < n; ++i)
sum += mat[i][i];
return sum;
}
/* C90 */
double trace(size_t n, double mat[])
{
double sum = 0;
size_t i = 0;
for(; i < n; ++i)
sum += mat[i * n + i];
return sum;
}
While this may not look like much of an improvement in simple cases, not having to manually emulate array subscription is quite convenient in more complex ones.
2. Allocation of variably-sized objects with automatic storage duration. Some libc implementations provide alloca() for that purpose -- unfortunately, it has issues (see eg http://c-faq.com/malloc/alloca.glb.html ).
Comments
I don't think VLAs would be that difficult to support as the underlying functionality (alloca) is already implemented by the compiler.
It's a matter of sanity, not difficulty. VLAs are not well-loved by many of the same people who write the compilers.
Perl Philosphy is simply to torment the implementors on behalf of the user -- Larry Wall
Look at the C99 rationale:
The inability to declare arrays whose size is known only at execution time was often cited as a primary deterrent to using C as a numerical computing language.
That's also the main reason for the introduction of complex types and type-generic math functions.
It's not as if the C committee got together and thought "Hey, what can we do to piss off compiler writers?" - there was actual demand for these features!
Sure, it made language semantics messier (runtime evaluation of sizeof, introduction of variably-modified types restricted to block or prototype scope, magical macros for math functions - which has been fixed with C11, btw), but C99 is indeed a superior language than C90 for doing numerics.
I don't dispute for a moment that some people wanted VLAs or that they're useful in some contexts. On the other hand, your cited field is relatively small, and the use case could have been satisfied with a mechanism much more in line with the existing language.
In fact, we've de-facto had such a mechanism for decades, but it hasn't been codified anywhere, actually for some of the same reasons people don't appreciate VLAs, but it at least rests much more comfortably with the rest of the language.
At some point, you go from enhancing C to breaking it in the interests of a small minority (who apparently don't want to use Fortran?). VLAs are, if not over the line, right on it.
On the other hand [...] the use case could have been satisfied with a mechanism much more in line with the existing language.
In fact, we've de-facto had such a mechanism for decades
Unfortunately, that's not the case. There are actually two primary use cases for VLAs:
1. Variable-length multi-dimensional array parameters:
While this may not look like much of an improvement in simple cases, not having to manually emulate array subscription is quite convenient in more complex ones.2. Allocation of variably-sized objects with automatic storage duration. Some libc implementations provide alloca() for that purpose -- unfortunately, it has issues (see eg http://c-faq.com/malloc/alloca.glb.html ).