Stack Exchange Network

Stack Exchange network consists of 175 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Visit Stack Exchange
3 added 164 characters in body
source | link

On Linux, if compiling code with GCC, the static data's constructor is run at dlopen(3) time. See also the visibility attribute and the GCC specific __attribute__((constructor)) for functions.

However, you should define a plugin convention: which names (for extern "C" C++ functions inside plugins) are used, with which signatures, in what order, etc.

For example, you could decide that every plugin should have a function extern "C" void my_plugin_init(void); which your program would run (after having dlsym-ed it) when loading a plugin, etc... That my_plugin_init might register some other functions (perhaps by adding them to some global std::map<std::string,std::function<BaseClass*(int)>> variable, etc....)

The Qt Plugins framework could inspire you.

On Linux, if compiling code with GCC, the static data's constructor is run at dlopen(3) time. See also the visibility attribute and the GCC specific __attribute__((constructor)) for functions.

However, you should define a plugin convention: which names (for extern "C" C++ functions inside plugins) are used, with which signatures, in what order, etc.

For example, you could decide that every plugin should have a function extern "C" void my_plugin_init(void); which your program would run (after having dlsym-ed it) when loading a plugin, etc...

On Linux, if compiling code with GCC, the static data's constructor is run at dlopen(3) time. See also the visibility attribute and the GCC specific __attribute__((constructor)) for functions.

However, you should define a plugin convention: which names (for extern "C" C++ functions inside plugins) are used, with which signatures, in what order, etc.

For example, you could decide that every plugin should have a function extern "C" void my_plugin_init(void); which your program would run (after having dlsym-ed it) when loading a plugin, etc... That my_plugin_init might register some other functions (perhaps by adding them to some global std::map<std::string,std::function<BaseClass*(int)>> variable, etc....)

The Qt Plugins framework could inspire you.

2 added 200 characters in body
source | link

On Linux, if compiling code with GCC, the static data's constructor is run at dlopen(3) time. See also the visibility attribute and the GCC specific __attribute__((constructor)) for functions.

However, you should define a plugin convention: which names (for extern "C" C++ functions inside plugins) are used, with which signatures, in what order, etc.

For example, you could decide that every plugin should have a function extern "C" void my_plugin_init(void); which your program would run (after having dlsym-ed it) when loading a plugin, etc...

On Linux, if compiling code with GCC, the static data's constructor is run at dlopen(3) time. See also the visibility attribute and the GCC specific __attribute__((constructor)) for functions.

However, you should define a plugin convention: which names (for extern "C" C++ functions inside plugins) are used, with which signatures, in what order, etc.

On Linux, if compiling code with GCC, the static data's constructor is run at dlopen(3) time. See also the visibility attribute and the GCC specific __attribute__((constructor)) for functions.

However, you should define a plugin convention: which names (for extern "C" C++ functions inside plugins) are used, with which signatures, in what order, etc.

For example, you could decide that every plugin should have a function extern "C" void my_plugin_init(void); which your program would run (after having dlsym-ed it) when loading a plugin, etc...

1
source | link

On Linux, if compiling code with GCC, the static data's constructor is run at dlopen(3) time. See also the visibility attribute and the GCC specific __attribute__((constructor)) for functions.

However, you should define a plugin convention: which names (for extern "C" C++ functions inside plugins) are used, with which signatures, in what order, etc.