[spongo2]

Hey, VC++ Dev Mgr here. Our official statement hasn't changed which is that we will enable major libraries but we need to prioritize C++ over C. Let me know if there is a library that is blocked that we don't know about and I will see what we can do. I will also say that the requests for C99/C11 seem to be increasing and we are listening. :)

[tacos]

Ex-Microsoft dev manager here. You have no idea what damage this has done to the dev community and Microsoft's reputation. It has caused so many people so much hassle.

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.

[haberman]

> Let me know if there is a library that is blocked that we don't know about and I will see what we can do.

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.

[angersock]

C99 has always been requested by people trying to write portable code, and you nice folks just haven't been listening.

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.

[StephanTLavavej]

The C99 Standard Library has been completed in 2015, including snprintf, with the exceptions noted in my post (tgmath.h and pragma macros).

[angersock]

Thanks!

Don't take our griping about standards-compliance too hard...speaking from experience, maintaining any STL-like codebase is a difficult effort. :)

Also, check here for some more examples of C99 tricks we might like (not tested with MSVC yet):

http://blog.noctua-software.com/c-tricks.html

[kps]

Speaking only for myself — just go for C11. Don't worry about the parts of C99 that even WG14 had to give up on.

  > but we need to prioritize C++ over C

It's 2015, and there's been an entire C++ Standard release in between, and the C++11 section of Stephan's chart is still not fully “Yes” — while the free compilers seem to implement draft C++17 features before the WG21 attendees get over their jet lag.

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.

[anarazel]

In Postgres we had to hack around:

* 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.

[xenadu02]

Our app is iOS and Android. When we implement cross-platform libraries we use C, specifically C11 because it is supported by both platforms.

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.