

Herb Sutter confirms no more support for C beyond C90 in Visual C++ - pjmlp
http://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99

======
binarycrusader
Should have been titled" Herb Sutter confirms that Microsoft's compiler group
management doesn't get it"

Even the IE team has learned the importance of implementing standards support.
Way to go guys; you've only had what, 12 years to get this right?

And one of your "solutions" to _your own_ organizational issues is to
"pressure your standards committee representatives to have ISO C++ include
more of the C standard (longer-term)."

Awesome! No wonder so many game developers prefer Intel's compilers.

I like the Visual Studio IDE, but this makes life so incredibly difficult for
cross-platform developers.

~~~
cobrausn
They are going to conform to a standard. The C++11 standard. Conforming to the
later C standards and the C++11 standard would be incompatible goals.

~~~
cdavid
How would supporting both C++ and C standards be incompatible ? Every other
major C/C++ compiler can do it (intel, clang, gcc, sun studio, etc…).
Implementing most of the C99 features is ridiculously easy compared to C++11
(C-compatible complex numbers, C99 semantics for inline, etc…).

The sheer amount of code that can be compiled on every platform but VS because
of this is very significant, especially open source ones. I have a hard time
buying the resource reason to be honest.

~~~
cube13
GCC and Sun Studio offer different compilers for C and C++. You _can_ compile
C code with Sun Studio's CC, but normally you would use cc for C code.

~~~
bunderbunder
The others, too. llvm, gcc, and icc all support both C and C++. But they also
support Fortran using the same technique: A separate compiler front-end for
each language.

For VC++ to add support for C as easily as many compiler collections do would
require VC++ having a modular architecture like that of the other compiler
collections. Considering VC++ only supports one language, that seems doubtful.

~~~
someone-else
It already supports C. They're just not updating the version, leaving it stuck
in C89 mode.

~~~
bunderbunder
Touche.

Perhaps I should have said "Supporting versions of C past the point where one
could plausibly just pipe the C code through a C++ compiler."

~~~
adgar
> Perhaps I should have said "Supporting versions of C past the point where
> one could plausibly just pipe the C code through a C++ compiler."

Like supporting for-loop variable declarations, which MSVC's C++ compilation
mode (/TP) supports, but MSVC's C compilation mode (/TC) does not?

Oh - and what about declaring a variable anywhere other than the start of a
scope? Allowed in C++, not in C. Cute.

------
blahedo
I'm seeing a lot of negativity here that I don't understand. The post seemed
fairly well-reasoned and reasonable; the objections seem to assume that the
content of the objection should be obvious. It's not obvious to me---C++ is
not a superset of C, and hasn't been for some time now, although there remains
a lot of overlap and cross-pollination. So why _shouldn't_ a C++ compiler
decide to just be a C++ compiler?

~~~
mikeash
I don't think there's anything wrong with having a dedicated C++ compiler. But
it seems fairly crazy to me for Microsoft not to have a C compiler that's even
remotely up to date. C is still an important language, and "just compile it as
C++" is _not_ a good answer.

~~~
bunderbunder
C is a very important language, but not so much among Visual Studio's target
market. Windows developers tend to be rather C++-centric, and I'm guessing the
biggest reason why the compiler team hasn't bothered is because there just
isn't sufficient demand to justify the diversion of resources.

I'm also guessing a lot of the world's C99 code has dependencies beyond the
just the compiler that Visual Studio won't support without some effort. "Just
compile it as C++" is not a good answer, but I wouldn't be surprised if "just
install Cygwin" often is.

~~~
waterlesscloud
There's still a ton of C legacy code running on windows machines out there.

~~~
mccoyst
You say that like they are removing all C support. Unless that "legacy" code
suddenly mutates to use C99 features that aren't in C++, it'll still compile
in the future.

~~~
waterlesscloud
But will never be updated to include C99 features. Exactly.

~~~
mccoyst
Exactly what? C99 doesn't have any killer features that legacy code would need
to "update" to. If a C89 program is working, adding unique-to-C99 features
isn't going to magically make it better.

------
mindstab
Wow, they go so far as to recommend gcc if you want "new" features. ~"We won't
support those features, if you want them go use a more full featured product".
Kind of makes it hard to keep peddling their product in the long term if they
plan to lag behind no?

~~~
eru
Depends. From the article it seems they position their product as a C++
compiler. You don't expect your Haskell compiler to also do OCaml.

~~~
fusiongyro
No, but I do expect my OCaml compiler to also do Caml.

------
revelation
Focus means saying no? Still laser focused twelve years after the fact?

Sorry, but it has always been clear that they just didn't want to invest any
kind of resources at all. Not even a few days of developer time for shipping a
freaking stdint.

------
klodolph
For me, it'd be fine if MSC (Microsoft's C/C++ compiler) supported a good
chunk the following features:

* 'restrict' keyword * C99 inline semantics * snprintf * flexible array members * designated initializers * UTF-8 string literals without using escape sequences * compound literals

Now I understand wanting to "focus" on C++, but some of the above are very
easy. For example, you can write snprintf as a three line wrapper around
_snprintf, and change the parser to accept restrict (it already accepts
__restrict). One would hope that since MSC already accepts wide characters,
adding UTF-8 support would be fairly trivial. (Right now, you can only put
UTF-8 in string literals either by tricking the compiler into thinking that
you're using an encoding OTHER than UTF-8, or by using escape sequences). I
would also hope that C99 inline semantics are easy to implement.

If we had those easy things, the bigger items (designated initializers,
flexible array members, and compound literals) would seem less.

------
pkmays
From the Dr Dobb's link:

> The C99 standard is interesting because it was created at a time when a lot
> of people on the previous committee went away and did other things. And it
> was a smaller group that came over who were interested in a special-purpose
> area, and so it ended up having a lot of things that were not of general-
> purpose interest.

Sutter's comment seems spot on about the apparent departure of a lot of the
original authors. C99 seems to have been designed by a group of people who's
overriding motivation was FORTRAN envy.

Really, how many people were screaming for built-in complex types, type-
generic math, or variable-length arrays? noalias even made it's way back into
the language.

Take the Good Parts of C99: BCPL comments, long long, and <stdint.h>, and
you've basically got MSVC's C compiler.

Good Parts of C11? Anonymous structs and unions. Plan 9 FTW.

------
josefonseca
There must be a strategical reason behind this, I can't believe they'd make
such a huge mistake.

One possibility is that they're trying to corner the native languages so
developers start migrating more and more into managed runtimes. This gives
Microsoft more power and control over what the programers are doing on their
OS. Removing C++ would be too big a hit, so killing off C is the compromise
they found.

The fact that they recommend GCC is intriguing though, I can't quite make
sense of that.

~~~
pjmlp
While I could agree with you, the fact is that all other compiler vendors,
that are also os vendors, are able to support both languages.

So why not Microsoft?

Their only excuse is that Windows developers don't care about C99, according
to their surveys.

Yet, this is one of the most requested features in Microsoft Connect.

------
angersock
I'm unsurprised, but still, goddamnit guys.

As one of the comments in the linked page points out, the problem with more
modern C code is that it tends to be covered in GCC gunk. Without Microsoft
implementing support, well, that won't get better.

Maybe one day Clang on Windows will be far enough along that Microsoft will
let you use it as a VS backend.

~~~
Someone
That would not solve that problem.
<http://clang.llvm.org/docs/LanguageExtensions.html>:

 _"Clang aims to support a broad range of GCC extensions."_

~~~
angersock
Well shit. :(

~~~
pmjordan
There's always

    
    
      -ansi -pedantic -std=c99
    

I actually find some of the GCC extensions quite nice for correctness. I
assume #defines that expand to nothing on other compilers still class as "GCC
gunk" though. :-)

~~~
cygx
Drop the -ansi flag, which enables C90 mode...

------
cygx
Thankfully, MSVC is not the only game in town.

I'm using GCC and Clang right now, but I'm also itching to try out Pelles C,
which comes with C11 support...

~~~
bratsche
But neither GCC nor Clang support Microsoft's debug symbols as far as I'm
aware. If you're writing libraries for Win32, your users are likely using
Visual Studio and they're going to get unhelpful stack traces without those
debug symbol files.

~~~
cygx
Mixing MinGW and MSVC object files is indeed a problem as neither toolchain
understands the other's debugging information.

If you can get away with it, just don't support MSVC. If that's not an option,
your best bet is probably restricting yourself to the common subset of C and
C++...

