[openal] Further consideration of C++

[Chris Robinson]

Some years ago, I brought up the idea of switching OpenAL Soft to C++ 
(leaving the ABI as C, retaining backwards compatibility). The main 
reason being MSVC forsaking C, not fully supporting C99 let alone C11. 
It makes it difficult to utilize more modern language capabilities for 
code safety, stability, and features, and I can't even ensure an MSVC 
build is properly optimized with the workarounds I've needed to do for it.

Since the last discussion about this, MSVC's C support has improved a 
little, some new C99-compliant functions and 'inline' works, but as of 
MSVC 2015, still no restrict, compound literals, designated 
initializers, type-safe atomics, generics, etc. More over, there's been 
quite a bit of work toward making C++ safer with clearer coding 
guidelines that compilers and error checkers can work with to deal with 
potential problems (RAII and stricter static type checking playing a big 
part).

When the switch to C++ was discussed some years ago, the concern was 
brought up that for binary apps on Linux, there could be conflicts if 
the system OpenAL relied on the system libstdc++, while the app itself 
is linked to an app-provided libstdc++. This would cause a problem 
because the app-provided libstdc++ can be older, so some symbols the 
system OpenAL may rely on would be missing. There are ways to work 
around this, but it's less than ideal if the user has to manually fiddle 
with files to get an app to run.

There may have been other issues brought up as well, but unfortunately 
it was before the switch away from Creative's mailing list so those old 
messages don't seem to still be available.


With the likely upcoming codebase split, I'd like to take another look 
at this. MSVC still shows no signs of really taking C seriously, and 
there are a number of benefits to have with "modern" C++ (11, if not 14 
or 17). All the hacky macro magic to implement things like dynamic 
arrays (including strings) and inheritance can be cleared away and 
replaced with standard features. A lot of the manual resource/memory 
management can be significantly cleaned up as well, removing who knows 
what bugs are hiding there.

The libstdc++ mismatch issue can be fixed by OpenAL Soft static-linking 
it. The system's libopenal won't rely on libstdc++*.so since it'll all 
be baked into the lib, as if it had coded those things itself in C. The 
linker is fairly good about removing unused stuff so the library size 
shouldn't increase excessively (especially if debug and symbol info is 
stripped). For C++ applications that provide their own libopenal build, 
there can be a compile-time option to dynamically link libstdc++ so your 
app and libopenal share the same libstdc++*.so code. Similar for 
Windows/MSVC's C++ runtime.


So all that said, I'd like to throw the idea back out there. Does this 
clear up the concerns you may have with OpenAL Soft using C++ 
internally? Are there any other new or remaining issues? Questions and 
feedback are appreciated. Thanks!