Hiya

I've recently taken a look at the FMOD API and I've noticed that it appears to be a C API, with a really thin C++ wrapper. I'm interested in understanding how they've implemented it.

The C++ classes in the header have no virtual methods or destructor, so they're not inheriting from these classes. Which makes me think that a member function like the following is implemented by just calling the equivalent C function:

FMOD_RESULT System::createSound(...)
{
  return FMOD_System_CreateSound(this, ...);
}

That C function takes a pointer to an FMOD_SYSTEM, which is declared like this:

typedef struct FMOD_SYSTEM FMOD_SYSTEM;

Which makes no sense to me. What does typedef'ing like this do, when FMOD_SYSTEM is undeclared? And how can the C function take an FMOD_SYSTEM parameter, but they must be passing a pointer to an FMOD::System class?

Many thanks!

What do the C++ headers look like? I don't have FMOD, but with more info about the header I could probably tell you what's going on.

You might be right about it being written or C, but it might be the other way around. They may have made a C-like C++ implementation to make it easier to put a C wrapper around their C++ code.

The typedef lets them avoid typing "struct FMOD_SYSTEM" everywhere. In C you cannot leave off struct in the type name unless you do a typedef. Without struct FMOD_SYSTEM defined, it's an incomplete type. Anything without the definition of what's inside the struct can only refer to it with a pointer. It's the C version of encapsulation.

I've been through adding a C++ library to a C program, and incomplete types are very useful in this situation. The C header may have its functions implemented in a C++ file, and that incomplete C struct could contain a C++ object inside, wherever it is actually defined. Or, they might never define it, and just force cast the pointer to whatever they use internally.

Thanks for the replies!

I've been through adding a C++ library to a C program, and incomplete types are very useful in this situation. The C header may have its functions implemented in a C++ file, and that incomplete C struct could contain a C++ object inside, wherever it is actually defined. Or, they might never define it, and just force cast the pointer to whatever they use internally.

Yep - that seems to be what they're doing. I can't tell whether they use a C++ object internally or it really is implemented in C. I guess they could have done this for compatibility reasons. They actually define the C++ factory function to call the C function below. Although FMOD_SYSTEM is an incomplete struct type.

inline FMOD_RESULT System_Create(System **system) { return FMOD_System_Create((FMOD_SYSTEM **)system); }

Are you using the official FMOD SDK? The Windows version contains .c and .cpp files for both C and C++ respectively which are both in the same folder for all the individual project files. In the SDK version that I have there is only C code in the .c file and the headers included both have .h extensions.

I have the public SDK, which doesn't include the source code.

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?

Thanks!

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?

Brett here from FMOD.

FMOD is written in C++ not C! :)

Here is the code we use. The C++ interface is the native interface, and the C header is actually a wrapper for the C++ interface. FMOD_SYSTEM is an opaque type that can be used interchangeably with the FMOD::System type. Its correct that having the C interface allows the DLL to export STDCALL symbols that any language can hook into. This is how we supported mingw/gcc/delphi/visual basic/C# etc.

FMOD_RESULT F_API FMOD_System_CreateSound(FMOD_SYSTEM *system, const char *name_or_data, FMOD_MODE mode, FMOD_CREATESOUNDEXINFO *exinfo, FMOD_SOUND **sound)
{
    FMOD::System *_system = (FMOD::System *)system;

    return _system->createSound(name_or_data, mode, exinfo, (FMOD::Sound **)sound);
}

FMOD_RESULT System::createSound(const char *name_or_data, FMOD_MODE mode, FMOD_CREATESOUNDEXINFO *exinfo, Sound **sound)
{
    FMOD_RESULT result;
    SystemI *systemi;


    result = SystemI::validate(this, &systemi);
    if (result != FMOD_OK)
    {
        return result;
    }
    else
    {
        return systemi->createSound(name_or_data, mode, exinfo, (SoundI **)sound);
    }
}

FMOD_RESULT SystemI::validate(System *system, SystemI **systemi)
{
    FMOD::SystemI *sys = (FMOD::SystemI *)system;
    
    if (!system || !systemi)
    {
        return FMOD_ERR_INVALID_PARAM;
    }


    if (!FMOD::gGlobal->gSystemHead->exists(&sys->mNode))
    {
        return FMOD_ERR_INVALID_HANDLE;
    }
    
    *systemi = sys;


    return FMOD_OK;
}

another trick we do is use reference counted integers for FMOD::Channel/FMOD_CHANNELs. People declare them as FMOD::Channel *, but they're not actually pointers to memory.

This allows us to error check the handle, and reference count it, so if it gets stolen by another channel, it will become invalid and channel functions will start returning FMOD_ERR_CHANNEL_STOLEN errors .. Like above , the ChannelI::validate function takes the base type in (the integer), and gives an implementation object out (FMOD::ChannelI). The validate function dissasembles the handle bitfield and looks up a table to get the correct FMOD::ChannelI object for internal use.

We have had support emails in the past about why our pointers look so strange, so we had to juggle some bits around so it looked more 'pointery'.