Wrapping different C API implementations in C++

Question

assume we were using gcc/g++ and a C API specified by a random committee. This specification defines the function

void foo(void);

Now, there are several implementations according to this specification. Let's pick two as a sample and call them nfoo and xfoo (provided by libnfoo and libxfoo as static and dynamic libraries respectively).

Now, we want to create a C++ framework for the foo-API. Thus, we specify an abstract class

class Foo
{
  public:
    virtual void foo(void) = 0;
};

and corresponding implementations

#include <nfoo.h>
#include "Foo.h"

class NFoo : public Foo
{
  public:
    virtual void foo(void) 
    {
      ::foo(); // calling foo from the nfoo C-API
    }
};

as well as

#include <xfoo.h>
#include "Foo.h"

class XFoo : public Foo
{
  public:
    virtual void foo(void) 
    {
      ::foo(); // calling foo from the xfoo C-API
    }
};

Now, we are facing a problem: How do we create (i.e. link) everything into one library?

I see that there will be a symbol clash with the foo function symbols of the C API implementations.

I already tried to split the C++ wrapper implementations into separate static libraries, but then I realized (again) that static libraries is just a collection of unlinked object files. So this will not work at all, unless there is a way to fully link the C libraries into the wrapper and remove/hide their symbols.

Suggestions are highly appreciated.

Update: Optimal solutions should support both implementations at the same time.

Note: The code is not meant to be functional. Perceive it as pseudo code.

Answer 1

Could you use dlopen/dlsym at runtime to resolve your foo call.

something like example code from link ( may not compile):

void    *handle,*handle2;
void (*fnfoo)() = null;
void (*fxfoo)() = null;


/* open the needed object */
handle = dlopen("/usr/home/me/libnfoo.so", RTLD_LOCAL | RTLD_LAZY);
handle2 = dlopen("/usr/home/me/libxfoo.so", RTLD_LOCAL | RTLD_LAZY);

fnfoo = dlsym(handle, "foo");
fxfoo = dlsym(handle, "foo");


/* invoke function */
(*fnfoo)(); 
(*fxfoo)();

// don't forget dlclose()'s

otherwise, the symbols in the libraries would need to be modified. this is not portable to windows.

Answer 2

First thing's first, if you are going to be wrapping up a C API in C++ code, you should hide that dependency behind a compilation firewall. This is to (1) avoid polluting the global namespace with the names from the C API, and (2) freeing the user-code from the dependency to the third-party headers. In this example, a rather trivial modification can be done to isolate the dependency to the C APIs. You should do this:

// In NFoo.h:

#include "Foo.h"

class NFoo : public Foo
{
  public:
    virtual void foo(void);
};

// In NFoo.cpp:

#include "NFoo.h"

#include <nfoo.h>

void NFoo::foo(void) {
  ::foo();   // calling foo from the nfoo C-API
}

The point of the above is that the C API header, <nfoo.h>, is only included in the cpp file, not in the header file. This means that user-code will not need to provide the C API headers in order to compile code that uses your library, nor will the global namespace names from the C API risk clashing with anything else being compiled. Also, if your C API (or any other external dependency for that matter) requires creating a number of things (e.g., handles, objects, etc.) when using the API, then you can also wrap them in a PImpl (pointer to a forward-declared implementation class that is only declared-defined in the cpp file) to achieve the same isolation of the external dependency (i.e., a "compilation firewall").

Now, that the basic stuff is out of the way, we can move to the issue at hand: simultaneously linking to two C APIs with name-clashing symbols. This is a problem and there is no easy way out. The compilation firewall technique above is really about isolating and minimizing dependencies during compilation, and by that, you could easily compile code that depends on two APIs with conflicting names (which isn't true in your version), however, you will still be hit hard with ODR (One Definition Rule) errors when reaching the linking phase.

This thread has a few useful tricks to resolving C API name conflicts. In summary, you have the following choices:

• If you have access to static libraries (or object files) for at least one of the two C APIs, then you can use a utility like objcopy (in Unix/Linux) to add a prefix to all the symbols in that static library (object files), e.g., with the command objcopy --prefix-symbols=libn_ libn.o to prefix all the symbols in libn.o with libn_. Of course, this implies that you will need to add the same prefix to the declarations in the API's header file(s) (or make a reduced version with only what you need), but this is not a problem from a maintenance perspective as long as you have a proper compilation firewall in place for that external dependency.

• If you don't have access to static libraries (or object files) or don't want to do this above (somewhat troublesome) approach, you will have to go with a dynamic library. However, this isn't as trivial as it sounds (and I'm not even gonna go into the topic of DLL Hell). You must use dynamic loading of the dynamic link library (or shared-object file), as opposed to the more usual static loading. That is, you must use the LoadLibrary / GetProcAddress / FreeLibrary (for Windows) and the dlopen / dlsym / dlclose (all Unix-like OSes). This means that you have to individually load and set the function-pointer address for each function that you wish to use. Again, if the dependencies are properly isolated in the code, this is going to be just a matter of writing all this repetitive code, but not much danger involved here.

• If your uses of the C APIs is much simpler than the C APIs themselves (i.e., you use only a few functions out of hundreds of functions), it might be a lot easier for you to create two dynamic libraries, one for each C API, that exports only the limited subset of functions, giving them unique names, that wrap calls to the C API. Then, you main application or library can be link to those two dynamic libraries directly (statically loaded). Of course, if you need to do that for all the functions in that C API, then there is no point in going through all this trouble.

So, you can choose what seems more reasonable or feasible for you, there is no doubt that it will require quite a bit a manual work to fix this up.

Answer 3

A linker cannot distinguish between two different definitions of the same symbol name, so if you're trying to use two functions with the same name you'll have to separate them somehow.

The way to separate them is to put them in dynamic libraries. You can choose which things to export from a dynamic library, so you can export the wrappers while leaving the underlying API functions hidden. You can also load the dynamic library at runtime and bind to symbols one at a time, so even if the same name is define in more than one they won't interfere with each other.

Answer 4

IIUC ifdef is what you need

put #define _NFOO in the nfoo lib and #define XFOO in xfoo lib.

Also remember if nfoo lib and xfoo lib both have a function called Foo then there will be error during compilation. To avoid this GCC/G++ uses function overloading through name mangling.

you can then check if xfoo is linked using ifdefs

#ifdef XFOO
//call xfoo's foo()
#endif

Answer 5

if you only want to access one library implementation at a time, a natural way to go about it is as a dynamic library

in Windows that also works for accessing two or more library implementations at a time, because Windows dynamic libraries provide total encapsulation of whatever's inside