102

I keep reading about C99 and C++11 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 is Microsoft more interested in adding new C# variants to do that?

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:

https://web.archive.org/web/20190109064523/https://blogs.msdn.microsoft.com/vcblog/2008/02/22/tr1-slide-decks/

Very useful. Thanks!

snipsnipsnip
  • 1,678
  • 29
  • 25
Colen
  • 12,368
  • 20
  • 72
  • 101
  • 3
    I don't understand what useful you found in the 2008/02 article from vcblog as the features described there have long existed in boost and quite well known. The world-changing features of C++0x are different: lambda functions, initializers, etc listed at http://en.wikipedia.org/wiki/C%2B%2B0x . – amit Jun 24 '09 at 08:48
  • See http://blogs.msdn.com/vcblog/archive/2009/04/22/decltype-c-0x-features-in-vc10-part-3.aspx recent article too (I know it is later than when the question was asked) – amit Jun 24 '09 at 08:52
  • 1
    This has been greatly improved in recent versions of Visual Studio, like 2015 Update 2: https://www.visualstudio.com/en-us/news/vs2015-update2-vs.aspx#Cdoubleplus – Ricardo Peres Jun 13 '16 at 10:36
  • Consider trying [MinGW-64](http://mingw-w64.org/doku.php) – Basile Starynkevitch Jul 13 '20 at 11:25

12 Answers12

103

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.

Community
  • 1
  • 1
jakobengblom2
  • 4,806
  • 2
  • 23
  • 30
  • 1
    "if you suspect MS wants to lock users in: it makes it very hard to port modern gcc-based code into MSVC". You would have been right if they had decided to not implement C++0x. But apparently, they are working (and working hard) on C++0x. So I guess they are not locking people out... – paercebal Sep 28 '08 at 18:58
  • 42
    Still, I guess their true reason is exactly what they said: The C community on Windows is perhaps almost non-existent, or negligible when compared to the C++/C#/.NET/ASP community. Thus, they have a valid point. Despite I have a Linux, and like g++, I won't scrap MSVC++ just because of C99, sorry. – paercebal Sep 28 '08 at 19:01
  • 11
    If they would at least give us for (int i;;) and inline. – Nick Van Brunt Feb 03 '10 at 17:05
  • @Nick : You can use a macro to define "inline" for C99-compliant compilers, and "__inline" for Visual C compiler. See : http://msdn.microsoft.com/en-us/library/z8y1yy88.aspx – paercebal Apr 15 '11 at 21:32
  • 12
    re: "lock-in" vs gcc: [Never ascribe to malice what can be blamed on incompetence.](http://en.wikipedia.org/wiki/Hanlon%27s_razor) – mskfisher Aug 24 '11 at 16:11
  • 2
    The best part of their reply concerning C++0x-oriented development is that now, over 4 years later, they still have barely any C++11 support. (Meanwhile gcc supports nearly the entire thing.) – GManNickG Feb 23 '12 at 05:00
  • I fail to understand why Microsoft fails to implement parts of C99 that *are already supported by C++* (like the `for (int i;;)` thing, being able to declare local variables anywhere, etc.). And even if they don't want to implement some of the language aspects, at least implement the libraries. A standards-compliant `snprintf` would be a nice start. – jamesdlin Feb 23 '12 at 05:41
  • 2
    @jamesdlin : By reading H. Sutter's Q&A, I believe the C compiler in Visual Studio is just there for historical support, and its aim is to support C89, nothing more, nothing less. The fact you can do all you asked in C++ by restraining yourself to C-like code could be another reason for them to avoid touching the C compiler. As for a standard compliant `snprintf`, I guess they believe one can find/write an conforming version. The point being: Implementing something means they must devote resources to maintaining it, and I guess for them, there is no compelling reason to do that for C99. – paercebal May 03 '12 at 19:13
  • @paercebal: The first item from that 2012-05-03 update (which you quoted in your answer) says that their "primary goal is to support most of C99/C11 that is a subset of ISO C++98/C++11". That's promising and is quite different from "support[ing] C89, nothing more". – jamesdlin May 03 '12 at 19:27
  • @jamesdlin : `1.` The part of C99/C11 which is part of C++11 could well NOT be what you need. . . `2.` you should be aware that Herb is talking about the C++ compiler having support for a limited part of C99/C11. Nowhere he wrote about the C compiler being upgraded to support anything C99 or C11. **Conclusion** : Are you sure it is really promising for a C developper not wanting to compile using a C++ compiler? – paercebal May 03 '12 at 20:40
  • @paercebal: 1. Well, in my earlier comment, I was specifically talking about C features that were already implemented in C++ (C++98, no less). 2. Although he was talking about the C++ compiler, it seems weird to explicitly mention it would support C99/C11 features that are a subset of C++11. That's already implicit if they're claiming to support C++11. Therefore my interpretation is that that subset of features also would be available when compiling C code. – jamesdlin May 03 '12 at 22:03
  • @jamesdlin : `Therefore my interpretation is that that subset of features also would be available when compiling C code` : Understandable. This is I mistake I would have done, too. Before reading that post from Herb Sutter, I didn't even realize the code for the C compiler was forever frozen. . . o.O . . . – paercebal May 04 '12 at 16:30
  • 10
    FWIW, [VC2013 preview](http://www.microsoft.com/visualstudio/eng/2013-downloads#d-2013-editions) is now supporting C++11 and C99 standards. Check out [what's new for C/C++ devs](http://blogs.msdn.com/b/vcblog/archive/2013/06/27/what-s-new-for-visual-c-developers-in-vs2013-preview.aspx). – vulcan raven Jun 27 '13 at 16:37
  • ICC is for GENUINEINTEL only, programs which it outputs will exhibit subpar performance on non-Intel processors. – Euri Pinhollow Feb 25 '17 at 10:12
37

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/

Community
  • 1
  • 1
paercebal
  • 75,594
  • 37
  • 124
  • 157
  • 1
    To be fair - the boolean implementation in C99 was done to allow backward-compatibility with sane code (i.e. code that defined bool to have boolean). – Maciej Piechotka Apr 14 '11 at 12:07
  • @Maciej Piechotka : You're right. I don't remember exactly the point I was trying to do there. I guess I mixed out Boolean and Complex: While the C99 Complex type is a good try, it remains a special case which needed a full C committee to appear. What about matrices? or math/physics vectors? What is laughable is the effort needed to add one useful type in C, complete with casts and operators support, when compared to doing the same thing in C++. C99 is incomplete, by nature. Looking at the `_Generic` feature of C1X, I see the same limitation again, a broken hack of function overloading... – paercebal Apr 14 '11 at 22:34
  • 19
    This: "Most interesting C99 features are already present in C++" is just false. Hexadecimal floating-point formatters and literals. C99 math library functions. Named initializers for structs/unions. The `restrict` keyword. There are a ton of great C99 features that are missing from C++, and they are features that I use every day as a C programmer. – Stephen Canon Apr 14 '11 at 22:57
  • 1
    @Stephen Canon : Please read my answer at: http://stackoverflow.com/questions/3879636/what-can-be-done-in-c-but-not-c/3880281#3880281 . Of course, this is a C++ answer for C++ developers, so it is not suitable for C developers unwilling to use classes, constructors, or overloaded math functions (who needs tgmath.h in C++?). The point being: What matters is already there, or easy to implement. As for the `restrict` keyword, you can still use in C++, apparently: http://stackoverflow.com/questions/776283/what-does-the-restrict-keyword-mean-in-c/1965502#1965502 . . . – paercebal Apr 14 '11 at 23:17
  • C++ support of `restrict` is compiler-dependent, not part of the language. I notice you don't address hexadecimal floating-point at all. Named initializers for aggregates are vastly better than constructors when you don't need full-on C++ objects. I agree that tgmacros are horrible, but I don't use them. Many C compilers support overloading anyway (If we're allowing C++ compiler support of restrict, fair's fair). The point is, they're *two different languages* with two separate communities of users, and that's not about to change. – Stephen Canon Apr 14 '11 at 23:24
  • @Stephen Canon : "I notice you don't address hexadecimal floating-point at all." Perhaps because this feature is not a fundamental feature. I mean, of course, to you, it must be important. But perhaps the majority of developers care little, if at all, about this feature. I, for example, would exchange none of the newly addition of C++0x for this hexadecimal notation. – paercebal Apr 14 '11 at 23:41
  • 1
    @Stephen Canon : "Many C compilers support overloading anyway" : Could you give me names of C compilers supporting function overloading? Or perhaps are you talking about C++ compiler compiling C-style code? – paercebal Apr 14 '11 at 23:45
  • Fwiw I consider the absence of hexadecimal floating-point literals an embarrassment. And I don't think I'm alone in that viewpoint. We have hexfloat formatting in the library. It isn't a stretch to think we also need hexfloat literals. I know of 3 C++ compilers that support this as an extension with the right flags turned on. – Howard Hinnant Apr 15 '11 at 00:00
  • @Howard Hinnant : Every non-optimal detail in a language is an embarrassment for someone. Although this is not a democracy, I guess the C++ committee gave priority to features considered more important by the larger C++ community. Perhaps for the next C++ version. And the same goes for Visual C++. They are not "forgetting" C99 out of spite. They are just giving priority to features their community needs, and today, I guess this is C++0x. – paercebal Apr 15 '11 at 00:16
  • 5
    @paercebal: you're entitled to that viewpoint, but there's nothing in **C++** that would entice me to give up hexadecimal floating-point literals. This is exactly my point. *Of course* C++ programmers don't care about C99 features; that's probably why they're C++ programmers. Conversely, there's a whole world of C programmers out there who don't care at all for C++ features, and just want Microsoft to provide a C compiler that at least tries to adhere to the standard like everyone else's does. – Stephen Canon Apr 15 '11 at 00:19
  • I would also point out that Howard actually serves on the C++ committee (thank you, Howard!), and presumably knows exactly why hexadecimal floating-point literals are not present. – Stephen Canon Apr 15 '11 at 00:23
  • @paercebal: Completely agreed. My intent was to agree that C++11 isn't perfect, I consider lack of hexfloating literals a defect, and that I hope to correct this in the future. A perfect standard takes an infinite amount of time and I'm very happy with C++11. As far as I'm concerned, work has already started on C++1x and I hope to see hexfloating literals there. We already have existing implementation experience in this area, so imho it looks promising. No guarantees of course! – Howard Hinnant Apr 15 '11 at 02:23
  • @Stephen Canon : "there's a whole world of C programmers out there who don't care at all for C++ features, and just want Microsoft to provide a C compiler" Almost all C99 have an equivalent in C++, meaning that a C programmer using a C++ compiler could still have his/her VLAs, or whatever. And whatever remains not implementable is not considered important enough for a large enough community to justify the time spent on it by the Visual Studio team. In the end, the importance of this "whole world of C programmers" is where we disagree, I guess. – paercebal Apr 15 '11 at 18:56
  • 13
    @paercebal: "equivalents" are useless. There are millions of lines of portable C code that work just fine on every other platform. Are you suggesting that they be rewritten? The C99 user community is sufficiently large that *every* other major compiler vendor at least attempts to deliver compatibility: IBM, HP, Apple, Intel, GNU, Sun, ARM, innumerable embedded device compilers, etc. C99 may not be important to *Windows* programmers, but Windows programs represent a tiny fraction of the total code written. – Stephen Canon Apr 15 '11 at 19:03
  • @Howard Hinnant : You're in the C++ committee? Wow!!! Thanks to you and all other members for C++0x, then (or C++11, as it is). It's a great work, it took time, but hey, it's amazing! – paercebal Apr 15 '11 at 19:06
  • @Stephen Canon : Your arguments are interesting, etc., but there are other compilers than Visual Studio on Windows, some supporting C99, so those "millions of lines of portable C code" can still be compiled on Windows. In the same way, speaking of Sun, their C++ compiler is so retarded we had to limit the C++ features we used in our production cross-platform code. So what? We lived with that, and found workarounds. I'm sure the C community can deal with the fact one "dumb" compiler on one "dumb" platform does not support C99. Even C1x's support of C99 is conditional... – paercebal Apr 15 '11 at 19:18
  • @paercebal: You're right, I should clarify: I would be perfectly happy if Microsoft admitted that they don't care about C and simply stopped claiming that they ship a C compiler. I don't care in the slightest whether or not MSVC actually supports C. – Stephen Canon Apr 15 '11 at 21:31
  • 1
    @Stephen Canon : More precisely. . . `1.` Microsoft more than once admitted the C Language is not their priority . . . `2.` Microsoft do ship a C compiler which supports C89 but not C99 (and they never claimed otherwise). – paercebal Apr 15 '11 at 22:06
  • 1
    @paercebal, C99 is supported starting from [VC2013 preview 1 (http://www.microsoft.com/visualstudio/eng/2013-downloads#d-2013-editions). Checkout the [official blog](http://blogs.msdn.com/b/vcblog/archive/2013/06/27/what-s-new-for-visual-c-developers-in-vs2013-preview.aspx). – vulcan raven Jun 27 '13 at 16:44
11

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.

vulcan raven
  • 29,699
  • 8
  • 51
  • 90
  • Only partial support for C99 as far as I can tell: http://blogs.msdn.com/b/vcblog/archive/2013/07/19/c99-library-support-in-visual-studio-2013.aspx "...We know that this is not complete support for the C99 library functions." – sdfqwerqaz1 Jan 29 '15 at 13:32
  • @sdfqwerqaz1, see the comment from STL [here](http://blogs.msdn.com/b/vcblog/archive/2014/11/17/c-11-14-17-features-in-vs-2015-preview.aspx): *"the compiler and library teams will consider them on a case-by-case basis, but our main priority is C++ conformance. For example, since C++11/14 incorporate the C99 Standard Library by reference, 2015 Preview fully supports the C99 Standard Library (with the only omissions being tgmath.h, which requires C compiler magic and is not relevant to C++ which has overloading, and CX_LIMITED_RANGE/FP_CONTRACT which also require compiler support)"*. – vulcan raven Jan 30 '15 at 09:47
8

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?

MSalters
  • 159,923
  • 8
  • 140
  • 320
7

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.

Dark Shikari
  • 7,761
  • 3
  • 24
  • 37
6

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

fbrereto
  • 34,250
  • 17
  • 118
  • 176
4

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.

JesperE
  • 59,843
  • 19
  • 133
  • 192
4

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.

OregonGhost
  • 22,433
  • 5
  • 66
  • 105
4

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:

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
Michael Burr
  • 311,791
  • 49
  • 497
  • 724
3

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.

QBziZ
  • 2,888
  • 20
  • 24
3

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.

David Scruggs
  • 129
  • 4
1

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

Pixelchemist
  • 21,390
  • 6
  • 40
  • 70