
Rejuvenating the Microsoft C/C++ Compiler - ingve
http://blogs.msdn.com/b/vcblog/archive/2015/09/25/rejuvenating-the-microsoft-c-c-compiler.aspx
======
exDM69
This is _excellent_ news. MSVC is a big pain in the ass for me, as I tend to
write C code (not ++ usually) and Microsoft's C compiler is the one with the
worst support for language level features (out of widely used compilers). E.g.
having to move variables to beginning of block (c89 style) is just miserable.
A popular option is to compile C code as C++ inside an "extern C" block to
stop name mangling, but this isn't too clean either.

I'd also like to have compatibility of some language extension features, such
as built-in functions and attributes. In particular, CPU-agnostic intrinsics
for common instructions like atomics, popcount or count leading zeros as well
SIMD arithmetic would be great.

My favorite C language extension is SIMD vector arithmetic with infix
operators. You can get really pretty and portable (!) vector math code written
in Clang and GCC using vector extensions, but again, it's not available in
MSVC.

For most of my current projects, I have no intent of supporting the (current)
Microsoft C compiler. It's not worth the effort.

~~~
to3m
VC++ has historically been the odd man out, but it's improved greatly in the
last couple of versions. Certainly, VS2013 has reasonable support for a lot of
C99 code. My C99 code builds on clang (OS X), gcc (Linux), and VC++ (Windows).
Maybe I need to get more adventurous, but what I see as the key improvements
(designated initializers, compound literals, declarations (nearly) anywhere)
are now in place.

Main omissions I've noticed: printf isn't quite the same (no 'z' modifier, the
'n' forms are noticeably inferior), no VLAs.Also, standard library isn't POSIX
(which is not an omission but a lot of C code assumes POSIX so you'll probably
end up having to deal with this).

I'm surprised you mention intrinsics, since VC++ has a wide selection -
[https://msdn.microsoft.com/en-
us/library/hh977022.aspx](https://msdn.microsoft.com/en-
us/library/hh977022.aspx) \- and I'd expect, though without proof, the
differences between many of those available on both VC++ and gcc/clang to be
something you could work around with #define or, failing that, a small inline
function (and cross your fingers).

Aside from VLAs, which is annoying, you can work around most of these with
wrapper functions and #defines. So I've been pleased enough with the latest
VC++. As a long time programmer for multiple platforms, I can put up with a
certain amount of deprivation, and having to put in a bit of effort doesn't
bother me (all that much). But I've noticed a tendency for people to sometimes
assume that "multiple platforms" means "ten different types of
gcc+POSIX+fork+pthreads". I'm sure that even shiny new C99-friendly VC++ won't
make them happy.

~~~
pjmlp
> But I've noticed a tendency for people to sometimes assume that "multiple
> platforms" means "ten different types of gcc+POSIX+fork+pthreads".

Having done multiple platform C development across Aix, HP-UX, Solaris,
GNU/Linux and Windows in the first .com wave, as well as, having some embedded
knowledge, it is always interesting that for some people only gcc and now
clang exist.

As for C99, Microsoft is pretty clear that are only supporting what is
required by the C++ standard.

~~~
ch_123
I believe they have started explicitly targeting C99 support in more recent
versions in order to make it easier to port C code developed against gcc or
clang.

Here's an older article -
[http://blogs.msdn.com/b/vcblog/archive/2013/07/19/c99-librar...](http://blogs.msdn.com/b/vcblog/archive/2013/07/19/c99-library-
support-in-visual-studio-2013.aspx)

(I've seen more recent ones, but I can't find an example to hand)

~~~
pjmlp
No they were pretty clear that it is only what is required by C++ standard,
and some high profile customers.

There was a C9 interview about it, need to search for it.

~~~
eatonphil
Out of curiosity, who are MSVCs high profile customers?

~~~
pjmlp
They didn't mentioned on the interview.

If I recall correctly it was at a Visual Studio event last year, on those
floor interviews they publish with the teams on C9.

~~~
cwyers
Adobe is almost certainly one:

[https://helpx.adobe.com/creative-suite/kb/microsoft-
visual-c...](https://helpx.adobe.com/creative-suite/kb/microsoft-visual-c-
runtime-error.html)

There's probably quite a few internal-only users of Visual C++ too.

EDIT: Well, they're a high-profile user of Visual C++, I have no idea if they
require C99 support but they ship a Mac version so it's possible.

------
simfoo
I hope Microsoft never decides to ditch their compiler and use something
existing like Clang. I may have had headaches due to Microsoft
incompatibilities before, but having a real alternative (or even three, MinGW
still works fine) is great.

That said I applaud their decision to fix their compiler architecture
problems!

~~~
claudius
There is also the Intel compiler (a bit pricy, but comes with enough bells and
whistles that for anything performance-related it is easily worth the money).
At least in my experience, its code is a couple percent faster than GCC on
modern Intel CPUs. Diagnostics are rather horrible, though.

~~~
azakai
I believe it has switched to use clang as its frontend, though, so it's not a
fully independent alternative anymore.

------
pornel
That's great. Please don't forget to finish the C99 implementation!

For tiny values I really like being able to use int arr[runtime_size]; rather
than risking buffer overflows with int arr[MAX_SIZE] or arr = malloc(size *
sizeof(oops)); — and MSVC is the last compiler that still doesn't support
that.

~~~
userbinator
VLAs do not absolve you of the need to ensure the buffer is the right size. In
fact, they can be worse since at least malloc()'s failure can be determined
from its return value. A VLA will just overflow the stack silently:

[https://www.clarkcox.com/blog/2009/04/07/c99s-vlas-are-
evil/](https://www.clarkcox.com/blog/2009/04/07/c99s-vlas-are-evil/)

Edit: to expand on this point, if you really need to keep all that data in
memory at once, it's often better to just malloc() a buffer of the appropriate
size and reuse it, reallocating if it should be bigger. (Obviously, do not
forget to free() it eventually.)

~~~
bluecalm
The point is that you sometimes want them on the stack and malloc won't do it
for you. MSVC has this already though: [https://msdn.microsoft.com/en-
us/library/wb1s57t5.aspx](https://msdn.microsoft.com/en-
us/library/wb1s57t5.aspx)

so I really don't think there is any good will there. It seems someone in the
management is set on "C++ is the future, C is obsolete" view, at least that's
the impression I've got from the press releases about it.

~~~
Peaker
If you want them on the stack, it's safer to use MAX_SIZE so that you don't
blow the stack when some arbitrary input arrives in the future.

~~~
bluecalm
1)There is sometimes a very slight performance hit as there is more space
between arrays and you miss on cache

2)using something which is smaller than MAX_SIZE is never worse unless you
write some safety critical software where a bug when you write to unintended
but empty location is better than writing randomly somewhere and/or crashing.
I prefer the latter in what I am doing (as it's easier to find something is
very wrong)

~~~
Peaker
The memory hit is an interesting point, could be useful if there's a static
validation on worst case stack size.

The smaller allocation is worse as it hides potential bugs.

------
MichaelGG
I guess I must have experienced some of this rewrite. With VC++ in 2015, a
piece of code that had a very long if/elseif chain no longer compiled. Parser
stack overflow: program too complex. Easy enough fix (break the if/elseif in
half) but funny in a way.

I hope they'll be able to continue to keep up C support as well as C++. It'd
been so nice having C99 in MSVC, as cross-platform projects can now adopt C99
features.

~~~
pjmlp
> I hope they'll be able to continue to keep up C support as well as C++. It'd
> been so nice having C99 in MSVC, as cross-platform projects can now adopt
> C99 features.

I hope that they only keep it as much as required by the ANSI C++ standard.

Annex K was a joke.

~~~
stephencanon
Annex K is optional.

~~~
pjmlp
Hence why it is a joke.

Not only has the standards comitte not done anything serious about preventing
bounds overflows, they made it optional.

Sizes still aren't guaranteed to be correct for the string/buffer.

No portable C code can rely on its presence.

~~~
stephencanon
AFAIK Annex K originated as a Microsoft proposal, so I find it somewhat
strange that you're using it as an example of a C feature that Microsoft
shouldn't adopt (though I agree that it's a terrible feature that never should
have made the cut).

~~~
pjmlp
Yes, as such there is nothing to adopt. It is already there.

What I am in favor is Microsoft pushing C aside.

C++ provides safer constructs and if one wants to keep on doing unsafe C style
coding, it is still there.

------
shmerl
So when will they support C99 (I'm not even asking about C11)?

~~~
pjmlp
They already do, to the extent required by the ANSI C++ standard.

~~~
shmerl
I mean C99 standard.

~~~
pjmlp
Partial C99 support is required by ANSI C++11 and C++14. This is what
Microsoft is currently supporting.

C++ is now supported on the kernel level.

Good luck doing WinRT applications with pure C.

------
malkia
This was some excellent information from Microsoft themselves.

Geoff Chappell has been uncovering various various Microsoft compiler and
linker (plus other bintools) hidden command-line options and environments
(like _CL, _CL_, and _LINK, _LINK_) -
[http://www.geoffchappell.com/studies/msvc/cl/index.htm?tx=23](http://www.geoffchappell.com/studies/msvc/cl/index.htm?tx=23)

------
pmelendez
> "we knew new features such as constexpr were going to need a different
> approach."

Stephan Lavavej (STL) also mentioned this a while ago. It is nice to see they
have been working on this so maybe MSVC can catch up with new standard
features faster from now on.

[https://news.ycombinator.com/item?id=9462644](https://news.ycombinator.com/item?id=9462644)

------
pantalaimon
> The target of the callback could not be found

~~~
comex
For posterity: the link used to pop an alert() saying that. Doesn't happen for
me anymore...

~~~
dEnigma
It still happens if you use STRG+F5 to force a complete reload.

------
lordnacho
Well I don't know if it's my machine upgrade or the VC++ upgrade, but my C++
code compiles an awful lot faster on VC2015. I also find the IDE tools very
responsive and useful. In particular you can now look at the implementation
next to the declaration.

~~~
spongo2
we made a bunch of improvements to build throughput especially for incremental
builds. many improvements to our handling of template code as well. -- steve,
vc dev mgr

------
makecheck
Now if they can just figure out how to make project files that aren't
completely and utterly incompatible with each other when they're only a few
years apart.

~~~
thwest
CMake comes with its own drudgery, but I find it better than trying to keep
Visual Studio project files in source control.

------
frozenport
Does static analysis still choke on Boost or CGAL?

------
blinkingled
Interesting that they mention using clang as the front end for their code
generation backend.

Glad that they're finally undertaking this, it'll take cross platform C/C++
code a long way if there's more standardization across all major compilers.

------
shadowmint
Come guys, just use clang!

It's state of the art, all the tooling already exists, and its under a very
permission license
([http://clang.llvm.org/features.html#license](http://clang.llvm.org/features.html#license)).

You don't need to rewrite all of these tools.

/me shakes head.

~~~
claudius
> It's state of the art

Does the officially released version support OpenMP by now? A few weeks ago at
least I still failed at installing that properly from official sources. There
seems to be an OpenMP-in-clang project going on, but it was far from obvious
what had to go where. So about this “state of the art”…

~~~
TillE
It took them forever, but yes, they support OpenMP 3.1 as of clang 3.7.

MSVC still only supports OpenMP 2.0.

~~~
claudius
This:

    
    
        ./clang++ --version
        clang version 3.8.0 (trunk 246030)
        Target: x86_64-unknown-linux-gnu
        Thread model: posix
    

does not support OpenMP to my knowledge.

~~~
gopowerranger
You have to enable it using -fopenmp

[http://blog.llvm.org/2015/05/openmp-
support_22.html](http://blog.llvm.org/2015/05/openmp-support_22.html)

[http://clang-omp.github.io/](http://clang-omp.github.io/)

~~~
claudius
Hmm, interesting. It works in a simple test case, but fails to compile my
codebase and throws an error

    
    
        ./inc/bla.h:163:9: error: unexpected '#pragma omp ...' in program [-Werror,-Wsource-uses-openmp]
        #pragma omp parallel for num_threads(Threading::num), schedule(dynamic, 1)
    

Unfortunately I wasn’t able to build a minimally failing example so far, I
will have to investigate this further. Thanks for the heads-up in any case!

Edit: Turns out everything fails if -Weverything is supplied. I didn’t offer a
runtime library (nor did the compiler define the _OPENMP macro even when
having -fopenmp on the command line, otherwise it would have complained about
a missing <omp.h>…). If -Weverything is not there, the thing compiles but only
runs with one thread.

