Is there any advantage to implementing a library like this using a C API, and then adding non-virtual C++ wrappers? I can't imagine many people want to use the C API, although I could be wrong. Possibly performance?
If you want a library to be linked (even dynamically) with anything generated by different compilers, there is really no way around a pure C API.
Even something simple as name mangling in C++ is not defined by the standard. In general two different different compilers will have different ways to encode the names and overloads of functions, so one compiler's linker will generally be unable to find the implementation of a function compiled by a different compiler simply because the name is not as expected. Then there are various ways the ABI
can be different. Even between different versions of the same compiler the ABI can break.
If you want C++ code linked, you really only have two options:
(1) offer it precompiled for all compilers your users are likely to use. Note that you will probably need more than one build per compiler. For example for MSVC you will often want at least two (Debug and Release build with dynamic runtime), possibly four (Debug and Release build with static runtime) and possibly more depending on specific compiler options. Also note that a static link will generally require an exact match of practically all parameters.
(2) offer the whole source so the user can compile it exactly the way he needs it.
Since FMOD is closed source and they don't want to prebuild tons of different versions for all kinds of compilers, a pure C API is really the only way to go. A thin C++ wrapper which does nothing more than map to the C API is not a big deal. It can be present in source without showing the actually important code and compiling the wrapper will be trivial (if it is not header-only to start with).
Note that option (1) above is far from simple. It places rather stringent restrictions on the runtimes involved, the parameter types you are allowed to pass to functions and how much care you have to take about where something is allocated and deleted (as one restrictions is tightened others can generally be relaxed).
Edited by BitMaster, 09 July 2013 - 01:32 AM.