Visual Studio 是否支持新的 C/C + + 标准？

Microsoft has never expressed any real interest in keeping up-to-speed with the c99-standard (which is getting old by now). Sad for C-programmers, but I suspect that Microsoft cares more for the C++-community.

Visual C++ 2008 SP1 contains parts of TR1 at least, and from time to time, the Visual C++ team is blogging or talking about C++0x, so I guess they will support it at some time in the feature. I didn't read anything official though.

MS has a series of public replies to this, most of them blaming their users. Like this one:

https://devblogs.microsoft.com/cppblog/iso-c-standard-update/

Now, the Visual C++ compiler team receives the occasionally question as to why we haven’t implemented C99. It’s really based on interest from our users. Where we’ve received many requests for certain C99 features, we’ve tried to implement them (or analogues). A couple examples are variadic macros, long long, __pragma, __FUNCTION__, and __restrict. If there are other C99 features that you’d find useful in your work, let us know! We don’t hear much from our C users, so speak up and make yourselves heard

http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=345360

Hi: unfortunately the overwhelming feadback we get from the majority of our users is that they would prefer that we focus on C++-0x instead of on C-99. We have "cherry-picked" certain popular C-99 features (variadic macros, long long) but beyond this we are unlikely to do much more in the C-99 space (at least in the short-term).

Jonathan Caves

Visual C++ Compiler Team.

This is a pretty sad state of affairs, but also makes sense if you suspect MS wants to lock users in: it makes it very hard to port modern gcc-based code into MSVC, which at least I find extremely painful.

A workaround exists, though: Note that Intel is much more enlightened on this. the Intel C compiler can handle C99 code and even has the same flags as gcc, making it much easier to port code between platforms. Also, the Intel compiler works in visual studio. So by scrapping MS COMPILER you can still use the MS IDE that you seem to think has some kind of value, and use C99 to your hearts content.

A more sensible approach is honestly to move over to Intel CC or gcc, and use Eclipse for your programming environment. Portability of code across Windows-Linux-Solaris-AIX-etc is usually important in my experience, and that is not at all supported by MS tools, unfortunately.

Herb Sutter is the chairman of the ISO C++ standards body and also works for Microsoft. I don't know about the Visual Studio C standard - mainly because I never use plain C - but Microsoft is sure trying to push the new C++ standard forward. Evidence of this is - like OregonGhost mentioned - the TR1 that is included in the latest Visual Studio Service Release.

Herb Sutter is both the chair and a very active member of C++ standardisation comitee, as well as software architect on Visual Studio for Microsoft.

He is among the author of the new C++ memory model standardised for C++0x. For example, the following papers:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2669.htm
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2197.pdf

have his name on it. So I guess the inclusion on Windows of C++0x is assured as long as H. Sutter remains at Microsoft.

As for C99 only partly included in Visual Studio, I guess this is a question of priorities.

• Most interesting C99 features are already present in C++ (inlining, variable declaration anywhere, // comments, etc.) and probably already usable in C in Visual Studio (If only doing C code within the C++ compiler). See my answer here for a more complete discussion about C99 features in C++.
• C99 increases the divergence between C and C++ by adding features already existing in C++, but in an incompatible way (sorry, but the boolean complex implementation in C99 is laughable, at best... See http://david.tribble.com/text/cdiffs.htm for more information)
• The C community on Windows seems non-existent or not important enough to be acknowledged
• The C++ community on Windows seems too important to be ignored
• .NET is the way Microsoft wants people to program on Windows. This means C#, VB.NET, perhaps C++/CLI.

So, would I be Microsoft, why would I implement features few people will ever use when the same features are already offered in more community active languages already used by most people?

Conclusion?

C++0x will be included, as extention of VS 2008, or on the next generation (generations?) of Visual Studio.

The C99 features not already implemented won't be in the next years, unless something dramatic happens (a country full of C99 developers appears out of nowhere?)

Edit 2011-04-14

Apparently, the "country full of C99 developers" already exist: http://blogs.msdn.com/vcblog/archive/2007/11/05/iso-c-standard-update.aspx#6415401
^_^

Still, the last comment at: http://blogs.msdn.com/vcblog/archive/2007/11/05/iso-c-standard-update.aspx#6828778 is clear enough, I guess.

Edit 2012-05-03

Herb Sutter made it clear that:

1. Our primary goal is to support "most of C99/C11 that is a subset of ISO C++98/C++11."
2. We also for historical reasons ship a C90 compiler which accepts (only) C90 and not C++
3. We do not plan to support ISO C features that are not part of either C90 or ISO C++.

The blog post add links and further explanations for those decisions.

Source: http://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99/

MSVC support for C is unfortunately very lacking. It only supports the portion of C99 that is a subset of C++... which means that, for example, it is physically impossible to compile ffmpeg or its libav* libraries in MSVC, because they use many C99 features such as named struct elements. This is made worse by the fact that libavcodec also requires a compiler that maintains stack alignment, which MSVC doesn't.

I work on x264, which unlike ffmpeg does make an effort to support MSVC, though doing so has often been a nightmare in and of itself. It doesn't maintain stack alignment even if you explicitly pass the highest function call through an explicit assembly-based stack alignment function, so all functions that require an aligned stack have to be disabled. Its also been very annoying that I cannot use vararrays either; perhaps this is for the best, since apparently GCC massively pessimizes them performance-wise.

I've been involved in the ISO C++ work (2000-2005), and Microsoft made significant contributions to that language. There's no doubt they will work on C++0x, but they'll need a bit more time than say Intel. Micosoft has to deal with a larger codebase that often uses their proprietary extensions. This simply makes for a longer testfase. Yet, they will support most of C++0x eventually (export still isn't loved though, or so I understand).

When it comes to ISO C, the people working on standard are not representative for Microsofts market. Microsofts customers can use C++98 if they're just looking for a better C. So why would Microsoft spend money on C99? Sure, Microsoft cherry-picked parts, but that's sane business. They'd need those for C++0x anyway, so why wait?

Updated information on this:

There is now (10 Nov 2008) a "Community Tech Preview" (CTP) of VS2010 which contains a preview of VC10 that has some parts of C++0x implemented (note that VC10 will not have the full set of C++0x changes implemented even when VC10 is released):

http://www.microsoft.com/downloads/details.aspx?FamilyId=922B4655-93D0-4476-BDA4-94CF5F8D4814&displaylang=en

Some details on what's new in the VC10 CTP:

• Visual Studio 2010 CTP released
• Lambdas, auto, and static_assert: C++0x Features in VC10, Part 1

As noted in the above article, "The Visual C++ compiler in the Microsoft Visual Studio 2010 September Community Technology Preview (CTP) contains support for four C++0x language features, namely:"

• lambdas,
• auto,
• static_assert,
• rvalue references

The Visual C++ team did put out a table of C++0x features that the 2010 release supports at http://blogs.msdn.com/b/vcblog/archive/2010/04/06/c-0x-core-language-features-in-vc10-the-table.aspx. Since there can be a lag time between the spec and the implementation, that seems pretty reasonable. Wikipedia has a nice article about the spec. It's not finished at the time I'm writing this.

A more recent post about MSVC's C++11 feature compatibility for MSVC 2010 and 2011 is now online.

Starting from VC2013 preview 1, C99, a more diversified set of C++11 and some newly introduced C++14 standards are supported. Checkout the official blog for more details: http://blogs.msdn.com/b/vcblog/archive/2013/06/27/what-s-new-for-visual-c-developers-in-vs2013-preview.aspx

Update:

From https://news.ycombinator.com/item?id=9434483 (Stephan T Lavavej aka: STL is maintainer of STL @VC team):

Specifically, in 2015 our C99 Standard Library implementation is complete, except for tgmath.h (irrelevant in C++) and the CX_LIMITED_RANGE/FP_CONTRACT pragma macros.

Check this post out for details: http://blogs.msdn.com/b/vcblog/archive/2015/04/29/c-11-14-17-features-in-vs-2015-rc.aspx.

The Visual C++ Bloq provides a lot of information on several interesing points regarding the support of C++11 in VC++11, including several tables

• C++11 Core Language Features
• C++11 Core Language Features: Concurrency
• C++11 Core Language Features: C99
• x86 Container Sizes (Bytes)
• x64 Container Sizes (Bytes)

Visual C++ Team Blog, C++11 Features in Visual C++ 11