Herb Sutter confirms no more support for C beyond C90 in Visual C++
herbsutter.com
herbsutter.com
Even the IE team has learned the importance of implementing standards support. Way to go guys; you've only had what, 12 years to get this right?
And one of your "solutions" to your own organizational issues is to "pressure your standards committee representatives to have ISO C++ include more of the C standard (longer-term)."
Awesome! No wonder so many game developers prefer Intel's compilers.
I like the Visual Studio IDE, but this makes life so incredibly difficult for cross-platform developers.
The sheer amount of code that can be compiled on every platform but VS because of this is very significant, especially open source ones. I have a hard time buying the resource reason to be honest.
. . . not actually very much. Visual Studio can use Intel's compiler, and perhaps others.
For VC++ to add support for C as easily as many compiler collections do would require VC++ having a modular architecture like that of the other compiler collections. Considering VC++ only supports one language, that seems doubtful.
Perhaps I should have said "Supporting versions of C past the point where one could plausibly just pipe the C code through a C++ compiler."
Like supporting for-loop variable declarations, which MSVC's C++ compilation mode (/TP) supports, but MSVC's C compilation mode (/TC) does not?
Oh - and what about declaring a variable anywhere other than the start of a scope? Allowed in C++, not in C. Cute.
Mission accomplished.
Any C++11 compiler that tells you it is also C11 standards compliant is not a C++11 compliant compiler. There are many things you can do with C11 that should cause an error under standards compliant C++11.
EDIT:
If they decide to make the /TP switch on the compiler turn it from C++11 compliant to C11 compliant, that basically makes it two compilers for two different languages, instead of restricting to a subset of C++11.
I'm asking for their C compiler to support the C99 or C11 standard.
They're not incompatible goals unless you're suggesting that they attempt to make a single compiler support both.
I'm also guessing a lot of the world's C99 code has dependencies beyond the just the compiler that Visual Studio won't support without some effort. "Just compile it as C++" is not a good answer, but I wouldn't be surprised if "just install Cygwin" often is.
Forcing legacy code to stay woefully out of date to support a single vendor's stubbornness, perpetually growing its maintenance burden as the rest of the world moves on. Hooray for the Microsoft way!
C90 isn't going away, and it's not Microsoft's fault. Many C compilers still support 1st edition K&R style for a reason — old C code is going to stick around, and it's probably not going to change much, let alone in any way that needs C99 features.
Ad 2) If there is support for features there will be people using them.
Sorry, but it has always been clear that they just didn't want to invest any kind of resources at all. Not even a few days of developer time for shipping a freaking stdint.
* 'restrict' keyword * C99 inline semantics * snprintf * flexible array members * designated initializers * UTF-8 string literals without using escape sequences * compound literals
Now I understand wanting to "focus" on C++, but some of the above are very easy. For example, you can write snprintf as a three line wrapper around _snprintf, and change the parser to accept restrict (it already accepts __restrict). One would hope that since MSC already accepts wide characters, adding UTF-8 support would be fairly trivial. (Right now, you can only put UTF-8 in string literals either by tricking the compiler into thinking that you're using an encoding OTHER than UTF-8, or by using escape sequences). I would also hope that C99 inline semantics are easy to implement.
If we had those easy things, the bigger items (designated initializers, flexible array members, and compound literals) would seem less.
> The C99 standard is interesting because it was created at a time when a lot of people on the previous committee went away and did other things. And it was a smaller group that came over who were interested in a special-purpose area, and so it ended up having a lot of things that were not of general-purpose interest.
Sutter's comment seems spot on about the apparent departure of a lot of the original authors. C99 seems to have been designed by a group of people who's overriding motivation was FORTRAN envy.
Really, how many people were screaming for built-in complex types, type-generic math, or variable-length arrays? noalias even made it's way back into the language.
Take the Good Parts of C99: BCPL comments, long long, and <stdint.h>, and you've basically got MSVC's C compiler.
Good Parts of C11? Anonymous structs and unions. Plan 9 FTW.
One possibility is that they're trying to corner the native languages so developers start migrating more and more into managed runtimes. This gives Microsoft more power and control over what the programers are doing on their OS. Removing C++ would be too big a hit, so killing off C is the compromise they found.
The fact that they recommend GCC is intriguing though, I can't quite make sense of that.
So why not Microsoft?
Their only excuse is that Windows developers don't care about C99, according to their surveys.
Yet, this is one of the most requested features in Microsoft Connect.
As one of the comments in the linked page points out, the problem with more modern C code is that it tends to be covered in GCC gunk. Without Microsoft implementing support, well, that won't get better.
Maybe one day Clang on Windows will be far enough along that Microsoft will let you use it as a VS backend.
"Clang aims to support a broad range of GCC extensions."
-ansi -pedantic -std=c99
I'm using GCC and Clang right now, but I'm also itching to try out Pelles C, which comes with C11 support...
If you can get away with it, just don't support MSVC. If that's not an option, your best bet is probably restricting yourself to the common subset of C and C++...