
Microsoft to C99 Developers: Use ISO C++ - T-zex
http://www.infoq.com/news/2012/05/vs_c99_support
======
ComputerGuru
We've been using a solution/workaround for ages because it was obvious MS was
never going to play ball.

Just install ICC (the Intel compiler). It hooks into Visual Studio, is a
better compiler for both C and C++ than MSVC, works really well, produces
really fast binaries, and does all its magic in the backend. Nothing changes
for you, the developer.

It's both free for non-commercial development and paid for commercial dev,
which makes perfect sense to me.

~~~
dman
Do you also instruct your customers to run on Intel chips for optimal
performance?

~~~
theatrus2
A very good point, as ICC is known to produce very bad code (intentionally)
when run on AMD systems.

~~~
masklinn
Technically, it does not produce very bad code when run on AMD systems, it
produces very bad code for running on AMD systems.

~~~
excuse-me
It avoids using some performance instructions which it uses on the Intel build
and which would work identically on AMD.

Their excuse is that they can't guarantee they would work identically on AMD
and so resort to much slower un-pipelined code. It's like Ferrari testing a
Porsche and only using 1st gear because they can't be sure that other gears
would perform in the same way

------
pkmays
Good for Microsoft. If they think something is standardized garbage then they
shouldn't have to use it.

C99 and C11 look like mutants compared to C89. Too many bad design decisions
made by a group of people who weren't involved with the initial
standardization. They even did the very thing the guy who _invented_ the
language explicitly told their predecessors in no uncertain terms not to do,
and reintroduced noalias pointers into the language [1].

[1] <http://www.lysator.liu.se/c/dmr-on-noalias.html>

~~~
stephencanon
Both C99 and C11 add many useful features to the language. I don't love all of
the additions, but I use enough of them everyday to consider them a net
benefit. It's still a vastly simpler and cleaner language than C++.

`noalias` was fundamentally broken, which is why _it was never adopted by the
committee_. Instead, `restrict` was standardized, but `restrict` does not
suffer from the problem that Ritchie highlights in the post you linked to.

It's also worth noting that C99 fixed some significant oversights in the C90
standard; C99 fully specified integer division for example (C90 left the
behavior implementation-defined for negative arguments).

~~~
pkmays
There are some Good Parts to C99/C11, most of them adopted from Unix and Plan
9. Not surprisingly, most of the bad parts are all inventions.

Read the link to dmr's comment again. His argument wasn't so much that noalias
was specified incorrectly, it was that the whole idea of adding any kind of
alias specifier to the language is against the spirit of C. I agree, and
apparently so did the C++ committee. If you want to write FORTRAN, write a
FORTRAN spec. Leave C alone.

------
dsrguru
There might be some merit to this. If you want a language that is very
portable and has a definition that is compact enough to be fully understood
both by you and by programs you might write that operate on source code
(static analyzers, interpreters, compilers, etc.), you are probably going to
use C89/90 instead of C99 (at least that seems to be what K&R felt--and what K
still feels). Otherwise, what advantages do you have in going with pure C99
over the C99 almost subset of ISO C++? Even if you don't really use any
language features unique to C++, you would still get some safer library
functions and better portability than you would if you limited yourself to the
C99 standard.

~~~
comex
If MSVC supported C99, it would be portable enough for the three major
platforms plus all the ports of GCC and any analyzers written for Clang/LLVM.
What do you get versus C++? Implicit casting of void *, so you don't have to
repeat yourself every time you use malloc, restrict, structure literals,
faster compilation (yes, the same code compiles faster in C mode than C++
mode, at least in gcc), not having to remember slightly different rules about
scoping, ...

~~~
dsrguru
What do you typically use in C99 that you don't get in C89?

~~~
_delirium
A few things I like, though not all of them are strictly needed:

    
    
        long long foo; /* bigger ints on 32-bit platforms */
        uint32_t bar;  /* stdint.h, integers of specific bit width */
        int array[n];  /* length-n array, where n is a variable */
        for (int i = 0; i < n; i++) /* loop-local variable */
    

Also, the safer stdio functions like snprintf.

~~~
yuhong
Some of them are already in MSVC.

------
codgercoder
Microsoft already filled the world with "C++" programmers by letting/making C
programmers use Visual Studio. All of a sudden they could put "C++" on their
resumes, even if they were really still doing C coding. That rather muddied
the waters, then. Now, C99 is undercut. what about C11?

------
diego_moita
Pelles is a very nice IDE and (LCC based) compiler with C99 & C11 support:
<http://www.smorgasbordet.com/pellesc/>

------
wickedchicken
C99 Developers to Microsoft: nope.

~~~
batista
Microsoft to C99 developers: don't let the door hit you on your way out. All
10 of you on the Windows platform.

------
SoftwareMaven
So why not use gcc or mingw? Is it just the IDE or are there other
complications? I haven't developed natively on Windows since the Borland
TurboC++ days, so I'm kind out out of the loop there.

~~~
breckinloggins
\- The VC compiler is actually really good, especially for Windows code
(obviously)

\- Visual Studio is a great IDE but more importantly it's what MS devs are
used to. It's harder to attract good MS developers if you don't support Visual
Studio

\- Binary compatibility issues between stuff compiled with gcc/mingw and stuff
compiled with VS (??? Someone chime in here if I'm wrong)

\- Gcc/mingw setup on Windows is perceived as more complex than installing VS

~~~
jhasse
>\- Binary compatibility issues between stuff compiled with gcc/mingw and
stuff compiled with VS (??? Someone chime in here if I'm wrong)

If you aren't using C++, everything should work fine. I've been using C
binaries from VS and mingw together without problems :)

~~~
excuse-me
'C' doesn't have name mangling

Mixing C++ binaries from different compilers is much trickier

------
aidenn0
MSVC has been essentially a C++ development environment for almost 2 decades
now. Asking for C99 support is a bit like asking for objective C support. MS
has made it abundantly clear that it would be unprofitable for them to add C99
support on many occasions before this.

------
bryze
Is anyone really surprised that Microsoft continues this behavior? For the
fan-boys (not that I expect there are many): the purpose of standards, whether
you like them or not, is to ease development and promote products with actual
value - not merely technology lock-in. Having maintained a C compiler for
Rabbit Semiconductor and read the C99 standard, I can say it is an improvement
on C90. Contrary to certain comments by Microsoft employees in the article
claiming irrelevance of C, it remains very relevant to the embedded systems
community. If we, as developers, want standards to prevail, we must eschew
nonconforming implementations. You've heard of "vote with your dollars", now
"vote with your code".

------
RandallBrown
What are some features of C99 and C11 that are _not_ part of C++?

~~~
stephencanon
Designated initializers, restrict, hexadecimal floating-point literals and
conversions. There are some others, but those alone are enough to prevent C++
from being interesting to me.

------
excuse-me
" If VS supported C99 natively, it would be easier for users to develop and
port existing cross-platform applications."

In the words of the noted philospher and business expert - "Well duh"

------
chj
vs sucks any way. this decision just makes it even worse.

