Support missing C99 features in plain C - stdint.h, declaration in the middle of the block, struct initializers with labels. C99 support is 12 years too late already.
Our primary goal is to support "most of C99/C11 that is a subset of ISO C++98/C++11.
We do not plan to support ISO C features that are not part of either C90 or ISO C++.
For more information, please read this Herb Sutter’s communication http://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99/
Please reconsider for VLC on ARM
Joe Marrero commented
Looks like we are not using Microsoft tools anymore. I hope after the poor reception of Windows 8, that Microsoft begins to listen to their customers.
In some point, MS helps promoting other platforms by neglecting certain technologies.
Unix-based platform providers get profits thanks to it - like Apple's XCode, which fully support C/C++ and Objective-C ( https://developer.apple.com/technologies/tools/whats-new.html#llvm-compiler ).
Dana, I bet single guy could add C99 features in less than a year. I bet even I, without knowing compilers well, could add C99 features given appropriate access to the source, in 1 year timeframe. But this is a question of principles
+1 for C99/11 features, from a big data and bioinformatics developer who would like to better support Windows.
I find it kind of humorous that C99 is ignored to "focus" on C++, when there appears to be plenty of cash at Microsoft for enormous wastes of resources like Zune and Windows Phone. I'd be willing to bet that C99/11 support could be added to Visual C++ for a fraction of the personnel costs of Enterprisey Tool - Humongous Edition (which will be entirely forgotten in a few years).
C is a very important language for the sciences and in CS. Not supporting the geeks that drive innovation is a horrible, horrible platform mistake. It's like eating your seed corn.
c99 support please
+1 for struct initializers... I want this sooo bad!
Looks like, we'll be forced to changed IDE's soon..
WTF? If religion doe**** allow to add support in the compiler - add at least the header files!
Why declined ?! Don't do this to us.. :/
For the love of pete get with c99 already.
Simon Dan commented
At least to support Native Variadic template of the C++11 iso, please...
@paerebal - it is not Herb this time who is sharing ideas. The forum exists for user to share their ideas. And what I was trying to do is to make clear that Microsoft does not make many friends in cross-plattform native development, nor in OSS community by declaring their C compiler C89(or even C98)-forever, and also diminishing the value of C as a language. Native low-level, close-to-the-metal development is still very much pure C. I hope the number of upvotes in this thread proves that point, Herbs answer also confirms that at least some people spent some time talking about it, though the overhyped C++ unfortunately for me won. I will raise that same suggestion next time and if that does not work out, again and again, and pretty sure collect more and more user votes.
@Vladislav Vaintroub : Herb is not "sharing ideas". He's trying to explain the reasons C99 won't be fully supported in VC++. I guess it is a more polite and constructive way to answer this thread than simply ignoring it, isn't it. He goes ever as far as offering alternatives, including compilers from the competition.
As for "Thanks or reminding us that user does not really have a voice", Visual Studio would probably support C99 if there were a majority of C99 users using it. The current situation is more, I guess, something like: "Implementing C99 will please a minority, and will divert the Visual Studio resources from development of C++11, as well as other languages (.NET? WinRT?) that would please a majority or are considered a priority".
@Vladislav: User feedback, here and on Connect, is indeed considered and appreciated. We try to always listen to feedback, we do discuss it internally (including again this C99 question in response to this thread), and we often say yes and implement the suggestions (e.g., we made community-suggested language support changes in the February beta such as adding range-for, and you can watch for further changes coming up in the coming months that we are making specifically in response to requests here and on Connect). But it should be clear that we can't say yes to all requests, even all popular ones -- I hope that having to say "no" on a given request isn't viewed by most people as lack of interest. We did spend time (re)considering this again in the past weeks specifically because it was raised here and because of the upvotes, and even though we decided to stay on our current course on this suggestion at this time we wanted to take time to create a reasoned answer.
@Herb, if you already chose your directions then there is absolutely no reason to share ideas. Thanks or reminding us that user does not really have a voice.
@Wolfgang: We realize that and sympathize with your situation. If you want a full conforming C99 mode that does (a) most/all of C99 and (b) nothing in C++ not in C99, we don't have good support for either and we do not plan to have support for that (sorry).
Our focus is on making a world-class C++ compiler, and we're heads-down on C++11 conformance. 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, 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), and 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. 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++.
We recommend our C customers use #1 as the best option for them if suitable for you, and we also provide #2 as a fallback alternative if suitable for you.
However, I understand that this leaves a hole for you because we do not plan to support C in any other way, and let me say it again explicitly:
3. Visual C++ does not plan to support ISO C features that are not part of either C90 or ISO C++.
If you really need: (a) features in C95/C99/C11 that are not part of ISO C++; or (b) features in C that are in the C++ subset but without also enabling the writing of C++ code; then it's true we don't have a solution for you and 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).
FWIW, I understand you 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) in C++.
Wolfgang Keller commented
Your comment implies that it is enough to be able to compile C(99 or 11) code properly. When you do a multiplatform project you sometimes have some trouble compiling the code you created with Visual Studio on Linux. By coding very cleanly according to the standards you can minimize the required changes you have to apply.
Now I decide to apply your hint and use the /TP switch to compile my C code as C++. The problem is: I can not only use C(99 or 11) features, but also features from C++. As soon as I try to compile the code under Linux, I'll get compilation errors if it is not clean C99 code. Summarising: it is not enough to be able to compile C99/11 code - the compiler frontend has also to check whether my code is really C99/11 or just C++ code in C99/11 disguise.
Even if this is solved: as soon as some colleague (who develops under Linux) decides to apply some changes in my C(99 or 11) code, he can never be sure whether the features he uses are available under Visual Studio, too - even if he codes close to the standard to be cross-platform. Thus I have the fear of having lots of trouble to get his code to compile under Windows.
If these arguments don't convince you: Microsoft's compiler business competition from Intel already supports C99 ;-)
Actually, Visual C++ 2010 already supports two of the three language features requested in the question.
Visual C++ is primarily a C++ compiler, but it can already be used to compile much C code that is a subset of Standard C++, including <stdint.h> and declaring variables in the middle of blocks.
We recommend that C developers use the C++ compiler to compile C code (using /TP if the file is named something.c). 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. This is the best choice for using Visual C++ to compile C code. [Note that the Visual C++ 11 beta adds a few more C++11 features, including some C-compatible types like atomic_int that happen to also be part of both C11 and 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.]
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).