I occasionally get asked about whether, or how well, Visual C++ supports C99.
- This week, I just posted two replies to this questions on UserVoice (merged below).
- Last fall, I also answered it in an interview with Dr. Dobb’s (recommended for some rationale discussion).
The short answer is that Visual C++’s focus is to support ISO C code that is supported by ISO C90 or ISO C++ (98 or 11). For the longer answer, I’m combining my UserVoice answers below, plus an additional comment about restrict in particular.
Our focus in Visual C++ is on making a world-class C++ compiler, and we’re heads-down on C++11 conformance. For C programmers, 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, including things like <stdint.h> and declarations in the middle of a block.[*] 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).
- 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).
- 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. 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.
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++.
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).
Granted, however, there is also bad news for C programmers:
3. We do not plan to support ISO C features that are not part of either C90 or ISO C++.
I understand C programmers 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 like everyone but which we also contribute for potential standardization) in C++.
Recommendations
We recommend that C developers use the C++ compiler to compile C code (using /TP if the file is named something.c). This is the best choice for using Visual C++ to compile C code.
Alternatively, we recommend that C developers use the C90 compiler (using /TC or naming files as something.c) if you need to write C90 conforming code that exercises some of the rarer cases that in C++98 are illegal or have changed meaning. This is a fallback primarily intended to support historical C code.
If you really need either of the following:
- features in C95/C99/C11 that are not part of ISO C++; or
- features in C that are in the C++ subset but without also enabling the writing of C++ code;
then 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).
[*] Visual C++ also partly supports some C99 language features under a slightly different syntax and possibly with slightly different semantics. Notably, we support __restrict – we did (and could again) consider allowing the standard C99 spelling restrict here for this feature, but please understand that this is not as simple as it looks. Not only the VC++ team, but also the ISO C++ standards committee, considered adding restrict to VC++ and ISO C++, respectively. Although it was specifically suggested for ISO C++11, it was rejected, in part because it’s not always obvious how it extends to C++ code because C++ is a larger language with more options and we would want to make sure the feature works correctly across the entire language.
Sutter’s Mill 
One very minor request that shouldn’t require much effort: Could VC at least relax the antiquated C rule that requires putting variables before statements? It’s no longer present in C, and never was present in C++. Continuing to enforce it just isn’t helping anyone, and removing the check should be easy.
No C99? Fair enough, but I hope we will get exemplary C++ conformance, including two-phase lookup (at least as an option), so we stop having nasty surprises when porting our code to other platforms.
Not including it a few years ago might have made some sense, but nowadays, Visual Studio is the only compiler that doesn’t implement it among the ones that _really_ matter: {VS, gcc, clang}.
When we can expect to see a preview of what is planned for the next out-of-band VC++ compiler release?
Using gcc instead of VC is not just a short-term solution. ;-)
After re-reading my posts I realized that I was a bit overboard, specially because myself I am more for C++ than C.
So lets see if I can contribute my thoughts in a more expressive way.
C++ surely contains most of C, while being more type safe. As such the decision to make C++ the default systems language for Windows makes sense. The C compiler support is then more seen as a kind of migration support.
On the other hand, when you are developing in other higher level languages, regardless if they generate native code or not, C is the ABI used to talk to other languages at the code level.
This and the bias that, unfortunately, many on the open source community have against C++, make that the majority of native libraries are usually developed in C.
Currently there are two camps:
– The ones that don’t care about Microsoft’s lack of support for C99 and choose to support other compilers;
– The ones that are keen in still supporting Microsoft compilers and restraint themselves to C89
This of course complicates matters if, for whatever reason, external C99 source code has to be taken into a project.
The main issue with Herb’s suggestion to go take another compiler (gcc, icc, clang, ..) implies the following:
– increase on the build process’s complexity, as several tool-chains need to be maintained
– possible lack of debugging support with mixed compiler libraries (debug symbols mismatch)
– C runtime compatibility issues
As such, developers like myself, that develop multi-platform software, might consider to rely on a set of C and C++ compilers from a single source, on the use cases where Visual C++ is not a requirement for the project success.
Apple and all UNIX vendors are able to provide both set of compilers, compliant to latest standards.
Given Microsoft’s success on the desktop, one would expect that it would be possible to have the same set of available resources to keep support for both standards.
Of course this is only an issue on projects that need to integrate foreign C99 code, which I do concede, might be a minority on the Windows platform, and Microsoft has to foremost care for its direct costumers.
I hope this has come out better, than on previous comments.
Re. the Tiobe index, it:
1: is heavily gamed, and completely and utterly meaningless, and
2: shows Java to outrank C++ too. So should Microsoft also deliver a Java compiler?
There are a lot of popular languages around. What I’d like to see from Microsoft isn’t that their compiler tries to implement and support them all, but perhaps just that they make life easier for third-party compilers. Third parties have pretty much given up on implementing SEH, because of obscure patents and lack of documentation, for example.
Ideally, we wouldn’t *need* Microsoft to deliver a C compiler. Ideally, a third-party compiler would be a first-class citizen on Windows.
x
Personally, my priority is C++ (and C++11), and the way things are looking right now, I’m far from impressed with Microsoft on that front either.
C isn’t a huge deal to me. I know it matters to others, but we can’t realistically expect Microsoft to build and maintain a compiler for a language solely because it is popular.
Instead, as I said, I’d like to see more openness on the platform side. Less reliance on undocumented ABIs, so that third party compilers are able to pick up the slack.
In the ideal situation, Visual C++ would directly support compiling for specific dialects C90, C95, C99, C11, C++98, C++03, C++11, etc… I think that doing that would cause the compiler to suffer. C++ developers have a big reason to support C++11 because of the extraordinary number of enhancements…it’s too bad they couldn’t get more in to C++11, but that’s just how life goes.
I think that there is going to be some overreaction about the lack of official C99 support but not realizing that most of C99 (the really usable parts) are already part of C++98 and C++11. In fact, I think that there is probably only a small set of people who are investing in features that are not a subset of C++98/11. From an academic sense, nobody ever teaches these specialized features anyways. In fact C11 kind of shoots C99 in the foot by making some of these features optional anyways…meaning there are a lot of compilers out there that don’t want to invest in these fringe features. If there was a need, I think that compiling strictly to the C subset of C++98/11 would be better at supporting folks wanting to write truly portable code.
To jump into the C vs C++ camp, I think that they both have their place. Linus has a point about C++ in the sense that if you are not good at implementing object oriented techniques, then it is easy to build these huge abstractions which might actually just end up being bad. But if you have other software that then depends on these abstractions, then you have a real problem. You get into a position where you are stuck with bad abstractions that can’t just get switched out. Then to avoid getting into these problems, then you start to restrict what you can do with the language and ultimately you’re almost back at C style features so why not just use C?
Personally, I think C++ can be an extremely powerful tool for building software but yes you can blow your leg off if you’re not careful. C on the other hand is not as severe because the language is less complicated and supports inherently less complicated abstractions. The point is well written C++ code looks beautiful next to comparable C code. The second point is that many people cannot write beautiful C++ code. To combat that, the new C++ features are going to be able to make it easier to write better C++ code and better code to begin with.
Hopefully the ISO C and C++ committees will work together next time to make C a better subset of C++ while incorporating features that C programmers want. Personally, I’m glad to know that C90 support is being specifically included since I consider that to be the most “official” C dialect around.
C was the first language I used when I started programming and I used it extensively on a number of operating systems, so I have a lot of respect for it and its designer. However, as soon as C++ came out, I left C behind and never looked back. I think the small additions from C++ to C made C a better language.
Since C has started to evolve more significantly on its own though, i.e. vla’s and generic, C has got worse IMHO, so I’m keen to stop that rot and that is the base of my viewpoint I suppose. I appreciate people have other opinions on that, of course.
@turbo
FWIW, I think you have zero chance of convincing Herb to do much on C here. He has said clearly, if you don’t like it, use another compiler. That’s about as blunt as you get. I support that view in this case, but I also support your right to differ and champion your own view.
I think you might have more joy though if you follow Olaf’s suggestion of listing out what it is from C you find so important, and seeing if other people can offer you C++ work arounds? I imagine you already know them though, but resist that route for other reasons?
As far as I remember, the linkage problem is solved using the extern “C” construct.
Regarding Linus, he’s clearly a talented guy with some great achievements to his name so if he wants to use straight C in his main project, I don’t really object since he clearly gets results with without the distraction of template errors etc. Maybe I’d choose to limit myself too if I did what he does, but I don’t know since I don’t do what he does. His opinionated nature makes me laugh on balance more than it offends me though, in any case. He gets results and things like Git are brilliant.
What I am confident about though, is if I continued to use straight C now myself, I’d die in a swirling mess of pointers and memory allocation errors; so I wouldn’t make the choice to avoid a C++ compiler myself.
I do pity people coming to C++ though who are dieing in a mess of template compiler errors instead. I can see why they think staying with C is better. It’s just not my choice though. I bitch at STL, but I use it, and I think C++ will continue to evolve in a good direction. I’m less sure of that in the case of C.
My hope is Bjarne and Co. can get Concepts into C++Next, which I hear might not be the case? When templates are constrained and the errors from them are understandable, I think their promise will have been delivered.
Is Microsoft trying to throw away C langage for C++ only ? …
Thanks for being outspoken and sharing your thoughts with the community. I think what it comes down to is, Microsoft doesn’t care about code portability (or at least it is very low ranking on the priority list). Any chance of open sourcing your C90 compiler?
@turbokapitalisten
> I am surprised by the arrogance of C++ devotees here.
I think people (without C experience) genuinely just don’t know why some people / projects prefer C over C++.
Neither do I. Sometimes I see C apps that re-implement stuff like strings, vectors, lists and hash_maps in an OO way or use other constructs that’d be much simpler in C++.
Maybe one should describe what C features not in C++11 one is looking for. Low hanging fruit might be easy to get, but lots of people are requesting C++ (and XP) support too.
That said, I don’t get why it has to be en exclusive or. MS is a big company, it should be possible to do more. How come GCC has better C++11 support?
I’m confused. Point 2 says that the C compiler (which is run on .c files) will support only C90. However, point 1 says that the goal is support “most of C99/C11 that is a subset of ISO C++98/C++11”. If the C compiler will not support anything beyond C90, why even state point 1? If the C99/C11 functionality is going to be available only when compiling code as C++, then just say “the goal is to support C++11”. Isn’t it already implicit that a C++11 compiler would support C99/C11 features that are a subset of C++11?
There are lots of reasons to use a C compiler over a C++ compiler. I am surprised by the arrogance of C++ devotees here. Your simple answer to why people use C, seems to be that they are simply stupid and don’t know any better. I have been a C++ developer for 13 years, but there are still lots of cases where I would prefer C. Just using a subset of C++ is often NOT good enough. You want a compiler that tells you when you are using non-C constructs. You might want no name mangling. I prefer C when writing routines for script languages such as lua and python or code shared code that I want to use in an Objective-C program, or microcontroller programming. In those case I think C++ is usually more in the way than helpful. A lot of this is also about communication. I write in a very different style when writing C++ than when I write C. That is because the two languages have different idioms and traditions.
BTW I think Linus has provided good reasons for his arguments. The drapes his arguments in colorful language but there are well thought out arguments in there is you care to look, and not just brush him off because of the inflamatory style of his writing.
I can’t say I’m sad about this decision at all. But perhaps I don’t understand it. Why anyone would use a straight C compiler these days is beyond me. I can’t say I like a lot of the C extensions I’ve seen anyway in recent years, like vla’s, generic etc. I think people who want to use C should just use a C++ compiler and limit themselves to a C subset if they really have to and just stop using vla’s, generic, and the like. I’d rather see MS work on pure C++11 and then XP support. I haven’t found that much to agree with Herb recently, but on this subject, I think I might. As for the Linus quote, it makes me laugh but perhaps we shouldn’t take him too seriously, he’s a character. If he’s smart, he’ll use a C++ compiler himself and just avoid the bits he doesn’t like too.
Well, I won’t say what I think of this decision, but I’m very glad that Microsoft has finally come forward with an official position, and not left us wondering any longer. Thanks, Herb.
C++ is not garbage, and STL is not evil. I agree that they can be complicated, and there is room for improvement, but power tools can be complicated sometimes.
I go back and forth between C and C++ enough to know the differences. I much prefer working in C++. There are a few things that C++ could stand to learn from C, but mostly I feel much more comfortable with C++.
The biggest reason I want better C support is to support the billions of lines of C code that is NOT valid C++. That C code is not likely to be rewritten in C++ (or the C++ compatible subset of C) anytime soon (it ain’t broke, we won’t fix it), but it is still being maintained.
Some of the maintainers might start thinking that a 22-year-old standard like C90 might not quite meet their needs (strange, but it might happen), and might start itching for features from a standard that is only 13 years old. I know, they’re being unreasonable to expect that kind of support, but people can be crazy like that.
The result is that there is a lot of really good C code doesn’t work very well (or at all) on Windows. MinGW is ok but not great. You can often hack things to work with MinGW, but that’s just one more roadblock, often tipping the scales and making people decide to not support a Windows version. If Microsoft were to make a bit of an effort at making the Windows platform more compatible with this code, a lot more people would be comfortable using Windows as their platform. At least that’s my take on it.
Aaaah, another IE6 situation… “Can’t be bothered, we have a monopoly.” Wonderful.
@Kevin Herb talks about it here, close to the beginning of the video: http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/C-11-VC-11-and-Beyond
@Ivan
I’m not a C programmer and never touched it in my life, from the beginning it was C++ for me.
But out there, there is plenty of C code and libraries which I use in my C++ projects, that’s why on Windows platform I’m always going with MinGW not VC++.
Another reason is every major C++ compiler on this plant, always ships with a C compiler beside it. GCC, CLang, Open64, Watcom, ……… as others mentioned why not VC++??
@ Kevin could be this:
http://channel9.msdn.com/Shows/C9-GoingNative/GoingNative-Live-at-BUILD-Herb-Sutter-Joanna-Mason-Tony-Goodhew
not sure, dont have time to rewatch it now.
@Kevin
if I recall correctly that Build conference, it wasnt a talk, it was a 3 MS people talking behind a desk… Herb mentioning points you made and elaborating why it happened. If somebody knows the video please link.
@Ivan
I didn’t see this point in the Dr. Dobbs interview. Where did Herb make this point?
@ Kevin
Herb explained the problem… ppl wanted var templates really bad and MS focused on that, but they messed up so you dont get VT, and as a bonus you dont get a lot of other stuff that could have been done if VT werent the focus.
I don’t really care much for C features beyond what is in the C++11 standard. If there is some low-lying fruit, then go get it.
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. Some even made it into VC2010. Other important ones though are still lacking in VC2011: variadic templates, template alias, initializer lists, delegating constructors, deleted functions, C99 preprocessor — all supported by both GCC and Clang along with some support by other major compilers. Microsoft is no longer the champion of native development and it saddens (and as a Windows developer frustrates) me.
C# has had the spotlight for a long time and C# is a quality language and the love its received shows; but it’s time for Microsoft to focus again on catching up on native development. I would love to see Microsoft take the lead again, but I’ll be content if MS just catches up.
Andrew, is linus your hero? That guy is extremely arrogant and he never backs up his nonsense arguments. To properly criticize a language you’d have to be an expert in it, linus definitely isn’t an expert in C++ – otherwize he wouldn’t make such stupid statements.
@Ivan – Well, since you started with baseless claims, I’ll return the favor:
STL is evil. C++ is garbage. To quote Linus:
“Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out, that in itself would be a huge reason to use C.”
> pressure your standards committee representatives to have ISO C++ include more of the C standard
I can just imagine the C++ committee’s joy at requests like “My C compiler vendor says they’ll only implement features in the C++ standard, so please add _Generic to C++”
No thanks!
@Andrew VLAs are evil. :)
SmallVector is nice <3
http://llvm.org/docs/ProgrammersManual.html#dss_smallvector
@Olaf: I’m a C++ programmer (on the windows platform)!
But there is some existing C code with an reasonable license out there, which I have to port to C++ or VC like C code. I’m simply bored to port “portable” C Code to windows.
@Ivan – Just one reason? Ok, VLA’s.
“Our primary goal is to support “most of C99/C11 that is a subset of ISO C++98/C++11.”
That is great. But not useful for C programmers since you only provide it in C++ compiler.
Maybe you should provide a flag for C++ compiler so that C++ compiler only allows C subset of the language.
Suits me, I guess I just won’t port to Windows. Sucks for the Windows users but if you won’t add support then I will have to remain Linux/OS X compatible only.
Sounds like Windows as a platform can get ******.
As you can see from Wikipedia, Microsoft is the only compiler vendor not providing any support for C99 and later standard versions.
http://en.wikipedia.org/wiki/C99
So if the other vendors are able to, why not Microsoft?
@M.S. Babaei – give me one good technical reason for using C instad of C++. Even if STL is too slow for you you can still use 99% of the C in “almost C” subset of the C++. And TBH regarding asm- it has more of a place as a legit choice for deving special kind of aps than C. Again I like to be proven wrong. Give me one example where ISO C++ sucks compared to ISO C.
Sorry Herb, but this stance is backwards. It continues to amaze developers like myself that the VC++ folks put in absurd amounts of manhours for creation, maintenance, debugging, Q&A, etc. of ISO C++11 — a complete behemoth (and often unnecessary) — yet virtually none for C99.
It’s equally as amazing to hear you recommend gcc or Intel’s compiler; come on, you know this recommendation is a farce given VC’s heavy tie-ins to the Microsoft compiler. I realise this statement is you being realistic with recommending alternatives — and that’s noble (read: fine/acceptable) — but it’s simply side-stepping the real issue here.
As many of the other posters have stated, the amount of time it would take Microsoft to add native C99 support is incredibly nominal, so the request then becomes “after all these years, please disclose the *real* reason for the reluctance”. I think Sven above put it best: “With your denial of C99 you contribute to the fragmentation of the C Language.”
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.
I care about it for C++’s sake: it uses the same preprocessor.
“Meh, tbh 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.”
@Ivan
C is obselete!!!!
Tiobe Index shows that C is still the King!! Even Assembly is not obsolete.
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
Now I know the meaning of obsolete……
“We intend to implement all of the C++11 standard, which includes much of C99 — roughly, it includes the C99 preprocessor…”
So, you’re committing to fixing the preprocessor? It doesn’t even conform to C89, you know…
I think this is a rather silly approach. The Microsoft C compiler (the /TC version) is NOT C90. It accepts numerous Microsoft-only and C99-only extensions. There is a lot of low-hanging fruit that could easily be added to the C compiler that would make a lot of people happy with very little in the way of hurting backwards compatibility. I understand that the compiler front-end team is trying to keep its focus, but I think it is currently too focused on C++. C is important and deserves at least a little bit of attention.
There is a LOT of existing code out there that is valid C but is not valid C++. That code is not likely to be rewritten to make it work with Microsoft C. Instead, it will either be built using MinGW (which is a less-than-optimal experience) or the users will just switch to another operating system that has decent support for C (which is one of the most important programming languages in the world). I think the lack of Microsoft support for C really is costing Microsoft customers.
Compiler front-end support could easily be added to support some of the simpler additions to C11. Even if the support isn’t exactly 100% compliant, you could get 98% compliance for several C11 features with very little work. If necessary for backwards-compatibility, these changes could be conditionally provided via a /Zc flag. I know that no change is free, but I think a little love would go a long way here. At least a token effort, please?
Should be easy to fix:
– Anonymous structures should not be considered “nonstandard extension”.
– C++ comments should not be considered “nonstandard extension”.
– Flexible array members should not be considered “nonstandard extension”.
– Keyword “inline” should be recognized and treated the same as existing keyword “__inline”.
– Keyword “restrict” should be recognized and treated the same as existing keyword “__restrict”.
– Keyword “_Alignof” should be recognized and treated the same as existing keyword “__alignof”.
– Keyword “_Pragma” should be recognized and treated the same as existing keyword “__pragma”.
– Keyword “_Noreturn” should be recognized and treated the same as existing attribute “__declspec(noreturn)”.
– Keyword “_Thread_local” should be recognized and treated the same as existing attribute “__declspec(thread)”.
– Keyword “_Static_assert” should be recognized and treated the same as C++ keyword “static_assert”. As a temporary easier fix, it could be treated the same as existing keyword “__static_assert”. __static_assert is not 100% the same as _Static_assert (__static_assert can be used in scopes where _Static_assert is illegal), but it’s probably close enough to satisfy most people.
– Preprocessor token “__func__” should be recognized and treated the same as existing token “__FUNCTION__”.
– A supported (guaranteed to continue working in the next version) way to express INFINITY and NAN as a compile-time constant. Currently, INFINITY=(DBL_MAX+DBL_MAX) and NAN=(INFINITY-INFINITY) work, but these are not entirely satisfactory until the compiler team agrees to maintain them as valid test cases.
– Define the appropriate macros for the features not supported, i.e. __STDC_NO_ATOMICS__, __STDC_NO_COMPLEX__, __STDC_NO_THREADS__, __STDC_NO_VLA__.
Might take a weekend to implement and a week to test:
– Support for declarations in the middle of the block. This exists in the C++ FE, so this may or may not be easy to port to C.
– Keyword “_Bool” should be recognized and behave like C++ bool. It should be a 1-byte unsigned type, boolVar in an expression should act like “(_Bool)(boolVar ? 1 : 0)”, and assignments “boolVar = x” should evaluate as “boolVar = (x != 0)”. Not sure how easy, but it would be really helpful to have a Boolean type in C.
– Keyword “_Alignas” should be recognized and work as specified. (This also needs to be done in C++.)
– Mixing string literals should be legal, e.g. { L”a” “b” } should be the same as { L”a” L”b” }. (This also needs to be done in C++.)
– Hexadecimal floating-point constants: 0x1.7ffp0L
– Keyword _Generic(type, selectors) is really cool and useful. It enables a lot of very useful situations in C but avoids name mangling linkage issues related to other implementations of “overloading”.
Better library conformance would also be nice, but library issues usually have reasonable workarounds.
Speaking of which, lack of XP and C99 support in VC11 is making me want to resume work on my “minwincrt” project. It was a very basic CRT implementation (STDC headers and lib) that worked with the VC10 compiler, tried to be C99-conforming, and linked as a static library to your app (so a simple “hello world” exe ends up being about 4k and depends only on kernel32.dll). Maybe I should go back to working on that. I don’t think there is any reason why it wouldn’t be able to work with VC11 and create XP-compatible apps. (Note that I don’t mean to say that I disagree with Microsoft making VC11 target Vista or later, since that helps keep the CRT size down and improve CRT performance. It would just be nice to have a fallback option.)
C++11 is enormously complicated compared to C99. Microsoft could have hired one or two guys to have made the changes to the frontend and library needed for C99 years ago, but has instead opted for making excuses all this time. Absurd, and incredibly frustrating for anyone trying to write portable code.
This is ridiculous. C outranks C++ (and now Java) on the Tiobe index. It is still an extremely popular and important language. You need to rethink your stance.
@Sven: How about moving to C++? Even on Linux there should be no reason to stick with C.
Meh, tbh 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.
It’s sad, on VC++ C has always been the second class citizen :(
While I do understand that is a business decision, it is an unfortunate one.
This way Microsoft clearly deprecates C support on its compilers, while the rest of the world keeps supporting C. As any other compiler in the market does have better C99 support than VC++ does.
If the other companies are able to do it, it surely it is not that hard.
Personally I would appreciate this C++ only attitude, if Microsoft would be keen to better support ISO C++, yet lots of development effort is spent in Windows only extensions that don’t bring any value to developers like myself that do multi-platform development.
Thanks for the clarification, now I know where to invest my company’s money.
I think this is a very reasonable explanation. C++11 support is clearly more demanded than a pure C99/C11 compiler. As a C++ programmer I’m happy with the C subset of C++, it’s important to keep the VC++ team’s resources where they should be – implementing C++11.
Also, as mentioned before, some official positive statements on the Windows XP issue are very welcome.
Hi Herb,
there is many so called C99 code out there, but that code is full of GCC extensions. At the moment everybody can declare all the code which don’t compile with the VC compiler simply C99 code.
So in my opinion we need a strong C99/C11 counterpart without the GCC extensions to get again more portable C Code.
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.
Regards,
Sven
I propose the next Reader Q&A to be titled: “What about VC11 and XP?”
(Just kidding. Hopefully an official response will be made in a few weeks as stated by Steve Teixeira.)