Visual Studio support for new C / C++ standards?

Question

Hello everyone,

I keep reading about C99 and C++0x and all these totally sweet things that are getting added to the language standard that might be nice to use someday. However, we currently languish in the land of writing C++ in Visual Studio.

Will any of the new stuff in the standard ever get added to visual studio, or are microsoft more interested in adding new C# variants to do that?

Thanks!

Edit: In addition to the accepted answer, I found the Visual C++ team blog:

http://blogs.msdn.com/vcblog/

And specifically, this post in it:

http://blogs.msdn.com/vcblog/archive/2008/02/22/tr1-slide-decks.aspx

Very useful. Thanks!

Answer 1

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.

Answer 2

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.

Answer 3

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

http://blogs.msdn.com/vcblog/archive/2007/11/05/iso-c-standard-update.aspx

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.

Answer 4

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.

Answer 5

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).
• C99 increases the divergence between C and C++ by adding features already existing in C++, but in an incompatible way (sorry, but the boolean 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

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.

Answer 6

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.

Answer 7

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?

Answer 8

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