One is not obligated to support all features of a standard in order to support some, a reality Microsoft has consistently availed itself of during its existence.
You really have no idea what my standards are. All I did was say they didn't have to support VLAs to support other parts of C99. That tells you absolutely nothing, stop assuming so much.
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 suspect that C11 support is closer than C99 support (and it would be good too). Things like variable length arrays are now optional.
There are exactly 2 features which were mandatory in C99 and are optional in C11: variable-length arrays and complex types.
C11 adds some non-optional features whch needs compiler support (alignment specifiers, type-generic selections, unicode literals, ...).
Do you really think vendors which don' care about C99 will suddenly jump to implement all mandatory C11 features?
Since it means not having to support VLAs, yes.
One is not obligated to support all features of a standard in order to support some, a reality Microsoft has consistently availed itself of during its existence.
So by your standards, Microsoft is doing quite well. After all, they do support parts of C99 such as stdint.h.
You really have no idea what my standards are. All I did was say they didn't have to support VLAs to support other parts of C99. That tells you absolutely nothing, stop assuming so much.
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 ).