Microsoft to C99 Developers: Use ISO C++
Microsoft has spent significant time and resources to promote developer interest in C++. The company's "Going Native" program has emphasized C++ development but what continues to be missing from this initiative is support for modern C as defined by the C99 standard. While compiler support for C99 varies across the industry, Visual Studio stands out by providing limited to non-existent compliance.
This failure to support C99 has frustrated developers requesting Visual Studio compatibility with the long time standard. If VS supported C99 natively, it would be easier for users to develop and port existing cross-platform applications. Google developer Josh Haberman recently listed several popular projects written in C in his recent plea for Microsoft to adopt C99. (Note that Haberman's website may be down, Google copy is available.)
Herb Sutter, Microsoft software architect and chair of the ISO C++ standards committee has recently commented on this situation, both on the Visual Studio User Voice forum and again on his personal website. In both cases he delivered a uniform message:
- Our primary goal is to support "most of C99/C11 that is a subset of ISO C++98/C++11."
- We also for historical reasons ship a C90 compiler which accepts (only) C90 and not C++.
- We do not plan to support ISO C features that are not part of either C90 or ISO C++.
Some of this has been stated before in various forms, but what is more interesting was the ultimate solution presented to those seeking C99 support: switch to a competitor's product or lobby the ISO C++ standards board to adopt changes that would increase support for C99 language. Pragmatically, switching to an alternative compiler is the fastest way to obtain C99 support. Less appealingly is trying to change what is a ostensibly a well thought-out language specification (C++11) by adding C99 related features.
End-user reactions vary wildly, depending on one's affinity for and need of, C99 code.
User Sven commented:
...A few years ago programming C was the right decision to create portable code. (write once – compile everywhere in opposite of compile once – run somewhere) But now we get C99 code for linux/gcc which doesn’t proper integrate into the windows platform.
With your denial of C99 you contribute to the fragmentation of the C Language.
C++ users offered a more positive reception of Sutter's message, as Ivan wrote:
Meh, [...] I dont really care and I support MS in not wasting resources on C. Bjarne often seems arogant but he is right: Use “almost C” subset of C++, C is obselete.
User Kevin H concurred, saying:
I am much more concerned with C++11 support. Even with the renewed focus on native development, it still feels like C++ is a second-class citizen inside the Visual Studio team. I understand the C++11 standard is new and that VC2011 was released at a bad time — at just about the same time the standard came out (C++98/VS6 all over again). However, there are features of C++11 that were set in stone long ago.
Anonymous sources cannot be verified by definition, but apparent Microsoft employee "anonymous" offers the following:
...Some of my peers/colleagues theorise that the real reason has to do with you being on the ISO C++ standards committee. Fact (and anyone who denies it is wearing rose-tinted glasses / has tunnel vision): C is still alive, very heavily used throughout everything — from frameworks to applications. Things that do not need anything C++ has to offer, but would greatly benefit from C99′s features that classic C90 does not provide. Yeah, it really is that simple.
So please — for the sake of developers, and for Microsoft — reconsider. And by the way (since over the years I’ve found this holds some bearing/weight, even though it really shouldn’t): I’m a Microsoft FTE (choosing to remain anonymous for reasons that should be fairly obvious to you). I hope this indicates to you that there are even those within the company that feel you’re truly not seeing the bigger need. Step up to the plate and do the Right Thing(tm). If you don’t know what “Right Thing(tm)” means, then therein lies the real problem.
10. Minimize incompatibilities with C++. The committee recognizes the need for a clear
and defensible plan with regard to how it intends to address the compatibility issue with
C++. The committee endorses the principle of maintaining the largest common subset
clearly and from the outset. Such a principle should satisfy the requirement to maximize
overlap of the languages while maintaining a distinction between them and allowing them
to evolve separately.
Regarding our relationship with C++, the committee is content to let C++ be the "big''
and ambitious language. While some features of C++ may well be embraced, it is not the
committee's intention that C become C++.
11. Maintain conceptual simplicity. The committee prefers an economy of concepts that
do the job. Members should identify the issues and prescribe the minimal amount of
machinery that will solve them. The committee recognizes the importance of being able
to describe and teach new concepts in a straightforward and concise manner.
At the WG14 meeting in London, England, in June 2007, the original principles and the
principles that were used for C9X were reviewed, and the following observations were
12. Trust the programmer, as a goal, is outdated in respect to the security and safety
programming communities. While it should not be totally disregarded as a facet of the
spirit of C, the C1Xversion of the C Standard should take into account that programmers
need the ability to check their work.
13. Unlike for C9X, the consensus at the London meeting was that there should be no
invention, without exception. Only those features that have a history and are in common
use by a commercial implementation should be considered. Also there must be care to
standardize these features in a way that would make the Standard and the commercial
14. Migration of an existing code base is an issue. The ability to mix and match C89,
C99, and C1X based code is a feature that should be considered for each proposal.
Already had to abandon C99 for C++ anyway
The C99 committee, with the mere justification of theoretically enabling more compiler optimizations, made type punning illegal, rejecting a suggestion that would have exempted programmer-indicated pointers from being considered non-aliasing. With a scratch of the pen, they invalidated millions of lines of existing code that, before, worked just fine. Because we increasingly needed C99 features such as fixed-size types in order to port our code to 64-bit and big-endian processors, our only choice was to convert wholesale to C++ instead, changing our existing implementation of C++-like features into the native C++ ones. Admittedly this move has been for the best anyway, and has enabled the software to grow dramatically faster, but as far as I am concerned, C99 is a broken standard that failed to maintain a necessary level of backward compatibility with its predecessor.