#include <gz/plugin/detail/Register.hh>
Go to the source code of this file.
Macros | |
#define | GZ_ADD_FACTORY(ProductType, FactoryType) DETAIL_GZ_ADD_FACTORY(ProductType, FactoryType) |
Add a plugin factory. | |
#define | GZ_ADD_FACTORY_ALIAS(ProductType, FactoryType, ...) DETAIL_GZ_ADD_FACTORY_ALIAS(ProductType, FactoryType, __VA_ARGS__) |
Add an alias for a factory. | |
#define | GZ_ADD_PLUGIN(PluginClass, ...) DETAIL_GZ_ADD_PLUGIN(PluginClass, __VA_ARGS__) |
Add a plugin and interface from this shared library. | |
#define | GZ_ADD_PLUGIN_ALIAS(PluginClass, ...) DETAIL_GZ_ADD_PLUGIN_ALIAS(PluginClass, __VA_ARGS__) |
Add an alias for one of your plugins. | |
Macro Definition Documentation
◆ GZ_ADD_FACTORY
#define GZ_ADD_FACTORY | ( | ProductType, | |
FactoryType | |||
) | DETAIL_GZ_ADD_FACTORY(ProductType, FactoryType) |
Add a plugin factory.
A plugin factory is a plugin that is able to generate objects that implement some interface. These objects can be passed off to a consumer, and as long as the object is alive, it will ensure that the shared library of the plugin remains loaded. The objects are handed off with a std::unique_ptr, so the raw pointer can be released from its std::unique_ptr and passed into any memory management system the consumer prefers.
The inputs and output of a factory are defined using the Factory class in the gz/plugin/Factory.hh header.
The first argument of this macro should be the class that implements the factory's output interface. The second argument should be the factory definition.
NOTE: If your factory has any input arguments, then you must define it outside of this macro, or else you will get a compilation error. This happens because macros will parse the commas between your template arguments as separators for the macro arguments. For example:
◆ GZ_ADD_FACTORY_ALIAS
#define GZ_ADD_FACTORY_ALIAS | ( | ProductType, | |
FactoryType, | |||
... | |||
) | DETAIL_GZ_ADD_FACTORY_ALIAS(ProductType, FactoryType, __VA_ARGS__) |
Add an alias for a factory.
This will do the same as GZ_ADD_FACTORY(), but you may also add in any number of strings which can then be used as aliases for this factory. For example:
This macro can be called any number of times for the same factory or for different factories. If you call this macro, you do not need to call GZ_ADD_FACTORY(), but there is nothing wrong with calling both (except it might imperceptibly increase your compile time).
◆ GZ_ADD_PLUGIN
#define GZ_ADD_PLUGIN | ( | PluginClass, | |
... | |||
) | DETAIL_GZ_ADD_PLUGIN(PluginClass, __VA_ARGS__) |
Add a plugin and interface from this shared library.
This macro can be put in any namespace and may be called any number of times. It can be called multiple times on the same plugin class in order to register multiple interfaces, e.g.:
Or you can list multiple interfaces in a single call to the macro, e.g.:
If your library has multiple translation units (.cpp files) and you want to register plugins in multiple translation units, use this gz/plugin/Register.hh header in ONE of the translation units, and then the gz/plugin/RegisterMore.hh header in all of the rest of the translation units.
◆ GZ_ADD_PLUGIN_ALIAS
#define GZ_ADD_PLUGIN_ALIAS | ( | PluginClass, | |
... | |||
) | DETAIL_GZ_ADD_PLUGIN_ALIAS(PluginClass, __VA_ARGS__) |
Add an alias for one of your plugins.
This macro can be put in any namespace and may be called any number of times. It can be called multiple times on the same plugin class in order to register multiple aliases, e.g.:
You can give the same alias to multiple plugins, but then that alias can no longer be used to instantiate any plugin.
If you give a plugin an alias string that matches the demangled symbol name of another plugin, then the Loader will always prefer to instantiate the plugin whose symbol name matches that string.