|library (string_view file_name, string_view version=string_view())|
|Constructs a library instance that will load the given library |
|library (const library &)=delete|
|Destroys the library instance. More...|
|string_view||get_error_string () const noexcept|
|Returns a text string with the description of the last error that occurred. More...|
|string_view||get_file_name () const noexcept|
|When the library was not yet loaded, the file name given in the constructor will be returned. More...|
|array_range< method >||get_global_methods () const noexcept|
|A range of all registered global methods in this library. More...|
|array_range< property >||get_global_properties () const noexcept|
|A range of all registered global properties in this library. More...|
|array_range< type >||get_types () const noexcept|
|A range of all registered type in this library. More...|
|bool||is_loaded () const noexcept|
|Returns true if the library is loaded; otherwise returns false. More...|
|Loads the library and returns |
|library &||operator= (const library &)=delete|
|Unloads the library. More...|
The library class provides a cross platform way of explicit loading shared objects (
.so on Unix based system and
.DLL on windows).
With a call to load() the library will be loaded and with unload() unloaded. The explicit call to unload() is not necessary. An internal ref count will trigger the unload automatically on application exit. So you are free the let the library instance go out of scope after loading, the type data will still be available.
After loading the library, the types of the plugin will be registered to the type system of RTTR. Use therefore the macro: RTTR_PLUGIN_REGISTRATION. The types or global properties or methods can be retrieved directly from the library class via getters.
Because the types are registered via RTTR, it is not necessary to additionally mark your types for export (e.g. using
__declspec( dllexport ) on windows). Furthermore, with using RTTR, it is possible to export overloaded methods (same name but different signature).
Copying and Assignment
A library object cannot be copied or assigned.
A typical usage example is the following: Some cpp file in your plugin called: "MyPlugin":
Now in your application, which loads the plugin:
Constructor & Destructor Documentation
Constructs a library instance that will load the given library
and an optional version number
The file name is expected to be encoded in UTF-8 format.
It is recommend to omit the file suffix, the library class will automatically look for a file with the native library suffix/prefix ( e.g.
.so on Unix,
.dylib on macOS and iOS, and
.dll on Windows)
Member Function Documentation
When the library was not yet loaded, the file name given in the constructor will be returned.
truewhen the library is loaded; otherwise
Unloads the library.
On application exit this happens automatically, so usually you don't need to call this function. When the same library is loaded multiple times, this call will not succeed before every library instance was unloaded.
- When you unload the library, make sure you don't hold any data (methods, properties or variants etc...) anymore, which was created by this library. Otherwise undefined behavior may occur (crash!).
truewhen the library was successfully unloaded, otherwise
The documentation for this class was generated from the following file: