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.
I actually find some of the GCC extensions quite nice for correctness. I assume #defines that expand to nothing on other compilers still class as "GCC gunk" though. :-)
Focus means saying no? Still laser focused twelve years after the fact?
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.
For me, it'd be fine if MSC (Microsoft's C/C++ compiler) supported a good chunk the following features:
* '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.
Wow, they go so far as to recommend gcc if you want "new" features. ~"We won't support those features, if you want them go use a more full featured product". Kind of makes it hard to keep peddling their product in the long term if they plan to lag behind no?
Microsoft has never seen Visual Studio as a profit center. It's just there because compilers are complements of applications that run on their system, which is a profit center. The only reason they even used to charge for it was to not kill Borland's compiler business. As long as there's a C compiler for applications on their operating system, they're happy. If someone else writes it, so much the better.
But neither GCC nor Clang support Microsoft's debug symbols as far as I'm aware. If you're writing libraries for Win32, your users are likely using Visual Studio and they're going to get unhelpful stack traces without those debug symbol files.
Mixing MinGW and MSVC object files is indeed a problem as neither toolchain understands the other's debugging information.
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++...
Should have been titled" Herb Sutter confirms that Microsoft's compiler group management doesn't get it"
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.
How would supporting both C++ and C standards be incompatible ? Every other major C/C++ compiler can do it (intel, clang, gcc, sun studio, etc…). Implementing most of the C99 features is ridiculously easy compared to C++11 (C-compatible complex numbers, C99 semantics for inline, etc…).
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.
The others, too. llvm, gcc, and icc all support both C and C++. But they also support Fortran using the same technique: A separate compiler front-end for each language.
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.
Of course I do. Doesn't the post make it clear as day? C++11 and C11 are different standards, as stated.
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 seeing a lot of negativity here that I don't understand. The post seemed fairly well-reasoned and reasonable; the objections seem to assume that the content of the objection should be obvious. It's not obvious to me---C++ is not a superset of C, and hasn't been for some time now, although there remains a lot of overlap and cross-pollination. So why shouldn't a C++ compiler decide to just be a C++ compiler?
I don't think there's anything wrong with having a dedicated C++ compiler. But it seems fairly crazy to me for Microsoft not to have a C compiler that's even remotely up to date. C is still an important language, and "just compile it as C++" is not a good answer.
C is a very important language, but not so much among Visual Studio's target market. Windows developers tend to be rather C++-centric, and I'm guessing the biggest reason why the compiler team hasn't bothered is because there just isn't sufficient demand to justify the diversion of resources.
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.
You say that like they are removing all C support. Unless that "legacy" code suddenly mutates to use C99 features that aren't in C++, it'll still compile in the future.
Exactly what? C99 doesn't have any killer features that legacy code would need to "update" to. If a C89 program is working, adding unique-to-C99 features isn't going to magically make it better.
> Unless that "legacy" code suddenly mutates to use C99 features that aren't in C++, it'll still compile in the future.
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!
I have severals problems with this. 1) The implication that working legacy code needs to be modified to use C99 features lest it be "out of date". 2) The idea that the world is moving on to newer C standards. 3) The idea that legacy code is moving on at all.
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 1) If C99 (or C11) was supported, you could perhaps use C99/11's features to refactor parts of the legacy code into more elegant code than possible with C89 (and yes, there are sometimes good reasons not to use C++).
Ad 2) If there is support for features there will be people using them.
It seems like kind of a self-fulfilling prophecy at this point. VS's dialect of C is literally more than two decades out of date at this point. Let your C compiler stagnate that long, and C developers will migrate to alternatives, leaving you with a C++-centric audience of your own making. I don't know if that's what happened, but evidently C was important enough at one point for them to support it.
They can get away with it because C has an ABI, so cygwin + gcc -mno-cygwin can build binaries that interoperate with Visual Studio's libc. Lots of open source projects build their Windows distributions this way - GTK for example has been doing it for about 10 years now.
> 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.
There must be a strategical reason behind this, I can't believe they'd make such a huge mistake.
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.
52 comments
[ 3.2 ms ] story [ 123 ms ] threadAs 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."
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.
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++...
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.
Mission accomplished.
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.
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.
> 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.