C++11/14/17 Features in VS 2015 RC

Hence, the desire to see MSVC support the C11 and C99 standards.

It's not an individual library--it's hack on hack on typedef on #define on hack to ensure compatibility, scattered across many projects.

If Microsoft is going to want to start winning over 'Nix developers, they need to get their shit together before somebody pairs a Windows port of Clang with a half-decent IDE.

EDIT:

A few things better than just a "aaaargh implement the standard" rant:

The threading and atomics in C11 would be really nice to have.

The features listed here ( http://blogs.msdn.com/b/vcblog/archive/2013/07/19/c99-librar... ) especially the snprintf support.

Last I checked, vsnprintf returns -1 instead of a useful character count when given a buffer too small, thus requiring use of _vsnprintf_s in a loop to try to figure out how much space is needed.

I'm not sure, but I think the most recent MSVC still doesn't support the "restrict" qualifier.

I'm sure there's other things as well.

EDIT2:

Part of the reason we want proper C99 support is that certain behaviors for implicit casting and whatnot change when done in a C++ compiler.

I want to know which VP nonchalantly set this stupid policy. And I want to know why nobody challenged the decision. Seriously, it's nuts. You had guys dorking around with IronRuby but there's no room in the budget to fix C?

The screams and requests for C99 have been DEAFENING for YEARS.

And I'm a C++ guy who could give a rats ass about it. I just cannot believe the disconnect here.

To reiterate what another commenter wrote, the question is not "what libraries cannot build?" but:

- what libraries have unpleasant hacks and workarounds sitting in their code-base?

- how much of an extra burden is imposed by having to accommodate MSVC, since its support for C99 is partial?

I'm happy that MSVC has been adding a lot of C99 features. But what will really make the difference is when it can say "supports C99", without major caveats. Because then we'll be able to write cross-platform libraries that target C99 without having to constantly tend to MSVC to check that we haven't broken the build on your platform. Or worse, made a design choice in API or implementation that requires a C99 feature not supported by MSVC!

I was excited to see C99 support in MSVC2013. I tried compiling my code-base against it. But then I ran into this bug: https://bellecrazysnail.wordpress.com/2013/11/14/some-though...

You can declare variables in the middle of blocks! As long as it's not a struct variable declared right after a brace-less if/while. Umm....

This is an example of having to "tend" to MSVC.

So if you want to gain trust, the question should not be: "who out there is still broken?" It should be "how can we make our compiler Just Work, instead of being something that everyone else has to accommodate all the time?" Apple has done it with Clang. Surely Microsoft can do it with MSVC.

We do not and will not make any effort to support MSVC. Failure to compile our libraries may have an impact on our already easy decision to disregard Windows Phone/Surface.

You are the ones fighting for developer mindshare these days. The onus is on you to justify making more work for people when your company would dearly like those people to consider porting their apps to Windows.

  > but we need to prioritize C++ over C

Having worked for a couple of big companies on large projects, so I can speculate: the code base is a metaphorical cross between an Augean stable and a house of cards, and the devs are lucky to manage an uninterrupted hour a week between meetings to actually work on it. I don't envy them.

Yeah, grumpy tonight.

* Lack of the C11 version of StaticAssert(), IIRC only the C++ version of static asserts is supported. Yay for things like #define StaticAssertStmt(condition, errmessage) \ ((void) sizeof(struct { int static_assert_failure : (condition) ? 1 : -1; }))

* A somewhat absurd version of printf/sscanf et al. We just always use our own now. Both from the POV of format characters available and

* Support for a _Alignas or something else than __declspec(align(8)) - it's often enough not possible to have declspec and other ways to specify alignment covered by a macro as they appear in different places.

* The support for signals and related is pretty damn poor, even for the subset that's in C99. That makes it e.g. much more annoying to write commandline tools that react sanely to interruptions and such. For the server itself we have a relatively large 'signal emulation' layer these days...

* No strto* (like strtoll)? Not that those are the nices API, but that seems to just require pointless effort, especially as _strtoi64() do exist.

And lots of other stuff that we just dealt with and then forgot about it. Most of it, except fork() not being available ;), can be dealt with. But it makes windows a far more annoying platform to deal with from the POV of cross platform development.

Windows is definitely the platform I see as being broken most often in our buildfarm. Part of that is due to the separate build system. Part of because fewer people know it well. But a good chunk is that it's just painful to develop for.

Oh, and could you make msvc realize in more cases that calling a declspec(noreturn) means that no further code is executed at the callsite? It'll frequently generate 'use of unitialized variable' type warnings when it's trivial to deduce that that code is unreachable.

Edit: formatting.