[openal] The future of MSVC support with OpenAL Soft

[Adam Moss]

Hi Chris,
VS2013's version of the C compiler finally got some love for the first time
in a billion years and does actually do a decent impression of supporting
C99.
--Adam


On 21 May 2014 18:57, Chris Robinson <chris.kcat at gmail.com> wrote:

> 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.
> _______________________________________________
> openal mailing list
> openal at openal.org
> http://openal.org/mailman/listinfo/openal
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openal.org/pipermail/openal/attachments/20140521/f677435a/attachment.html>