Using dlsym in c++ without extern “C”

Question

I have a system in which I give the user a function prototype and the user has to implement it. Now, I compile this file using g++ and load it dynamically using dlopen and d

Answer 1

You can use the mangled C++ name directly.

If you have e.g. a C++ function void my_plugin(int foo) , the C++ compiler will mangle that name. Once you know the mangled function name, you can use dlopen() on that name.

e.g.

# nm libmyplugin.so |grep my_plugin
00000000 T _Z9my_plugini

So here our function is named _Z9my_plugini , and you could do

 func = dlsym(handle, "_Z9my_plugini");

Traditionally different compilers could mangle the name in different ways, so this could be quite fragile, thoug these days most C++ compilers will aggree opon a standard way of mangling the names on a given platform.

However your users will be programmers, and they would normally have an understanding of exposing an entry to a dynamically loaded library as extern "C"

Answer 2

Since you are using C++, why don't you export only one (or two) functions that will simply return a pointer to some kind of pure virtual class, say IMyModule? The one (or two) exported extern "C" functions would be something similar to extern "C" IMyModule * create_instance_IMyModule(); (and extern "C" void delete_instance_IMyModule(IMyModule const *);).

Answer 3

Another alternative to extern "C" before each declaration is to use the block-style syntax:

extern "C" {

void my_callback();
int other_functionality( foo * );

}

Often the extern "C" { and closing brace } are wrapped in macros, which are conditional on the __cplusplus built-in macro, so the header can also be used from pure C. This also encapsulates the part you find objectionable.

In any case, I don't see what the big deal is. If the user can write in C++, they should be competent to enclose their C interface function prototypes in extern "C" when the library documentation tells them to.