What is the easiest way to write portable dynamically loaded libraries in C ++?

Question

I am working on a project that has several similar code paths that I would like to separate from the main project in plugins. The project should remain cross-platform compatible, and all the dynamic library loading APIs that I learned are platform specific.

What is the easiest way to create a dynamic library loading system that can be compiled and run on multiple operating systems without additional code modifications? Ideally, I would like to write one plugin and work on all the operating systems supported by the project.

Thanks.

Answer 1

You will need to use platform-specific code for the boot system . Different DLL loading on Windows than loading a shared object on Unix. But with a #ifdef pair, you can have basically the same code base in the bootloader.

Having said that, I think you can make your platform independent plugins. Of course, you will have to compile it for each platform, but the code will be 99% the same.

Answer 2

The dynamic library loading Windows and Unix / Linux has three functions. A couple of functions for loading / unloading libraries and another function for getting the address of a function in a library. You can easily write a wrapper around these three functions to provide support for cross-operating systems.

Answer 3

Ideally, I would like to write one plugin and work on all the operating systems supported by the project.

A few things from the head:

• Avoid static objects in dynamic libraries. Provide the correct initialization methods / functions for placing objects. The problems that occur during loading the library by the operating system (this is when calls are made to static objects) are very difficult to debug - there are only problems with multithreading.

• Interface headers may not contain code. There are no built-in methods not defined by the preprocessor. This is done in order to avoid ruining the application using code from a specific version of the library, which makes it impossible to replace the library at a later time.

• Interface headers may not contain the implementation classes themselves — only abstract classes and factory functions . As in the previous paragraph, to avoid application it depends on the specific version of the classes. Factories are needed as a way to apply a custom application to specific implementation classes.

• When introducing a new version of the interface, in order to keep something backward compatible, do not modify the existing abstract class - create an abstract abstract class inherited from it and add new methods there. Change factory to return the new version. (Remember MS 'IInterface, IInterface2, IInterface3, etc.). In the implementation, use a newer version of the abstract class. That polymorphism will make the implementation backward compatible with older versions of the interface. (This, obviously, requires periodic maintenance of the interface and cleaning - to remove the old crack).

Answer 4

Take a look at the boost.extension library, it is not part of the upgrade, but you can find it in the sandbox. This is also a frozen view, but in general the library is stable and easy to use.