- This week, I just posted two replies to this questions on UserVoice (merged below).
- Last fall, I also answered it in an interview with Dr. Dobb’s (recommended for some rationale discussion).
The short answer is that Visual C++’s focus is to support ISO C code that is supported by ISO C90 or ISO C++ (98 or 11). For the longer answer, I’m combining my UserVoice answers below, plus an additional comment about restrict in particular.
Our focus in Visual C++ is on making a world-class C++ compiler, and we’re heads-down on C++11 conformance. For C programmers, the good news is twofold:
1. Our primary goal is to support "most of C99/C11 that is a subset of ISO C++98/C++11."
- VC++ 2010 already fully supports the C subset of C++98, including things like <stdint.h> and declarations in the middle of a block.[*] The C subset of C++98 is approximately C95 (with very few incompatibilities with C95; i.e., there are very few cases where legal C95 code has a different meaning or is invalid in C++98) plus a few C99 features like declaring variables in the middle of blocks).
- VC++11 now in beta already adds partial support for the C11 subset of C++11 (e.g., it supports the new C11 atomic_int types for concurrency and parallelism).
- Soon after VC++11 ships we have announced we will do out-of-band releases for additional C++11 conformance which will naturally also include more C11 features that are in the C subset of C++11. We intend to implement all of the C++11 standard, which includes much of C99 — roughly, it includes the C99 preprocessor and library extensions but not the language extensions like restrict.
So we already support large subsets of C99 and some-and-soon-more of C11. Our immediate and long-term goal is to fully support the C subsets of ISO C++.
2. We also for historical reasons ship a C90 compiler which accepts (only) C90 and not C++.
For the (hopefully rare) cases where legal C90 code has a different meaning in C++98 and this matters to C developers, for backward compatibility with older C90 code we also continue to ship a C compiler that implements Standard C90 exactly (using /TC or naming files as something.c).
Granted, however, there is also bad news for C programmers:
3. We do not plan to support ISO C features that are not part of either C90 or ISO C++.
I understand C programmers may be disappointed or angry with this answer and I’m sorry to have to say no here. It’s true, and very quotable, that "focus means saying no," but that doesn’t make it easy to say — it is hard to say no to you, and I’m sorry to say it. But we have to choose a focus, and our focus is to implement (the standard) and innovate (with extensions like everyone but which we also contribute for potential standardization) in C++.
We recommend that C developers use the C++ compiler to compile C code (using /TP if the file is named something.c). This is the best choice for using Visual C++ to compile C code.
Alternatively, we recommend that C developers use the C90 compiler (using /TC or naming files as something.c) if you need to write C90 conforming code that exercises some of the rarer cases that in C++98 are illegal or have changed meaning. This is a fallback primarily intended to support historical C code.
If you really need either of the following:
- features in C95/C99/C11 that are not part of ISO C++; or
- features in C that are in the C++ subset but without also enabling the writing of C++ code;
then we recommend that you consider using a different compiler such as Intel or gcc (short-term) and/or pressure your standards committee representatives to have ISO C++ include more of the C standard (longer-term).
[*] Visual C++ also partly supports some C99 language features under a slightly different syntax and possibly with slightly different semantics. Notably, we support __restrict – we did (and could again) consider allowing the standard C99 spelling restrict here for this feature, but please understand that this is not as simple as it looks. Not only the VC++ team, but also the ISO C++ standards committee, considered adding restrict to VC++ and ISO C++, respectively. Although it was specifically suggested for ISO C++11, it was rejected, in part because it’s not always obvious how it extends to C++ code because C++ is a larger language with more options and we would want to make sure the feature works correctly across the entire language.