dll is a simple library used to manage the loading and calls of dynamic loaded libraries.

Let’s suppose you have defined a module library called my-module into a package called my-package. To load my-module from a library or an application:

• In CMakListst.txt:

PID_Component(my-new-code
                DEPEND  pid/dll
                        my-package/my-module)

• in my-new-code source code:

#include <pid/dll.h>
...
pid::DLLLoader dll("my-package","my-module");
auto func = dll.symbol<void()>("register_pid_plugin_extensions");
func();

• You have just to include pid/dll.h to get access to dll API.
• Loading of the DLL is made at DLLLoader object construction time, and unloading is automatically performed when object is destroyed.
• Use the symbol method to get the corresponding symbol or get an exception if the symbol does not exist. Use has_symbol to check whether a symbol exists.

Remark: Dependency to my-module in CMakeListst.txt is optional but is the preferred way because it lets PID version resolution automatically solve the version of my-module but also solve version for all its direct or undirect dependencies. The good point is that version resolution is globally secure, the bad point is that it forces to solve the global configuration of an application at its configuration phase which may be contradictory with highly runtime configurable plugin system.

The alternative is so to avoid declaring a dependency with the module:

PID_Component(my-new-code
                DEPEND  pid/dll)

Then in C++ code you can for instance do :

...
pid::DLLLoader dll("my-package","my-module", "1.4.3");

or

...
pid::DLLLoader dll("my-package","my-module", "+1.4.3");

The main difference here is that you must use a version constraint that follows the pattern defined by pid-rpath api. Previous code respectively tell to load the exact version 1.4.3 of my-package and to load any version greater or equal than 1.4.3.