[openal] The future of MSVC support with OpenAL Soft

[Chris Robinson]

Before I go further, I'd like to clarify that what I'm discussing here 
is /building/ OpenAL Soft. Compiling apps against pre-made binaries and 
using it with your apps will not be affected in any way.


It's no secret MSVC has poor support for C since C90. It's also no 
secret that they don't plan on fully supporting C99, C11, etc.

http://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99/

However, from what I can tell, the thing that's really problematic is 
that even the features they will be including in the future must work in 
the context of C++. This is because to get those features, you actually 
have to compile as C++. At that point, you're really just writing C++ 
code that masquerades as C, and as a result you won't have full C99/C11 
or C++ to work with. It's kind of telling that the lead architect of 
MSVC recommends GCC and Intel for proper C support.

As it is now, as of MSVC 2009 (the oldest MSVC version I currently care 
about), it didn't even support the inline and restrict keywords in C, 
things that were added to the language 10 years prior, despite the fact 
that is does support the (similar) __inline and __restrict keywords. 
Thankfully I can just define inline to __inline, and the compiler seems 
to be okay with using it like C99 (in regards to inline/extern inline 
definitions and declarations). The restrict keyword, however, doesn't 
fair so well. Although MSVC has __restrict, I can't define restrict to 
it because that breaks the __declspec(restrict) that Microsoft's headers 
use. So I have to disable restrict on MSVC by defining it away to 
nothing, which is pretty unfortunate since it can really help with 
compiler optimizations.

In addition, MSVC 2009 doesn't allow variable declarations in for() 
statements in C, as C99 allows. This would be something that could help 
with code cleanliness in places since pre-C99 also requires local 
variable declarations to be placed at the start of a code block. It can 
also be used to create some crafty macros to help ensure proper cleanup 
when a block of code ends (freeing a temporary memory pointer, releasing 
an object reference, unlocking a lock, etc) without nasty gotos, 
improving code readability and safety.

Going forward, I'd also really like to start using C11's atomic methods 
to decrease the amount of mutex locking needed in the mixer. This is 
something MSVC will/does support, but again, only when compiling as C++. 
Another thing I'd really like is C99's compound literals... and this is 
something MSVC will never support since IIRC the syntax is already used 
in C++ mode to mean something different. I'd also like C99's designated 
initializers -- that is, things like this:

struct timespec ts = { .tv_sec = sec, .tv_nsec = nsec };
int array[16] = { [0] = 1, [4] = 20, [10] = 52 };

... particularly when combined with compound literals.


Now, I'm not quite ready to drop MSVC support just yet. But it's clear 
that as C improves and diverges from C++, and as other C compilers 
continually gain new features, MSVC is always going to be the lowest 
common denominator, and it's not going to be improving at all without 
switching to C++. At some point, I imagine the hassle is just going to 
be too much to directly support it.

What are your thoughts? Am I correct in my understanding of how MSVC's 
C99/C11 support will work (i.e. only available in C++ mode, never 
complete), or have things changed? How necessary is MSVC build support 
if pre-built binaries are provided that will still work for developers? 
Are there alternative ways to indirectly support MSVC with newer C code? 
I know ffmpeg actually uses a wrapper program to convert their C99 code 
to something MSVC accepts, although it's incomplete.