Question

I want to have a plugin, with a simpler name to resolve in other C++ code.

class B {
};

extern "C" B foo(); // to avoid name mangling in order to be loaded by dlsym

And in the other part of the program (which is also in C++ and shares the same definition of class B with the plugin):

B (*func)();
func = dlsym("/path/to/so", "foo");
B m = func();

Will such code cause any problem, i.e. is it allowed (by standard) to use a C++ class as parameter or return type in an extern "C" function? It seems to work on my gcc, but what about the others?

Was it helpful?

Solution

That should work, with a few conditions:

  • If you intend to switch the definition of class B to something else, it won't work. The only thing you can change is the definition of foo().
  • Both the plugin and the loading program must agree on the interface of class B on a binary level. Switching compilers (including version and some flags) can change this interface.
  • You obviously have to cast the returnvalue of dlsym() in C++.
  • Using classes in C is not possible.

OTHER TIPS

Declaring foo() as extern "C" will of course allow you to load it through dlsym() using the actual, unmangled function name, but otherwise will have no effect on how you use that function after you load it.

The usual rules still apply. If you break binary compatibility of either foo() or class B, you will need to recompile the plugin, just as you would have to recompile it if it was a regular, non-runtime loaded dynamic library.

It will work as long as you are sticking to C++ and only to C++. For obvious reasons you will not be able to compile your function declaration in a C translation unit. (I.e. you will never be able to properly explain to C compiler what B is.)

So, the only issue I see here is what the meaning of [C] tag on your question is. Do you also need some sort of cross-compatibility with C?

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top