Skip to content


Switch branches/tags

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?
This branch is 4 commits ahead, 2 commits behind pikacic:master.

Latest commit


Git stats


Failed to load latest commit information.
Latest commit message
Commit time



The Plugin Manager is a small tool to add to a C++ application the possibility of dynamically instantiate (via factories) objects from classes defined in plug-in (or component) libraries.


To be able to use plug-ins from an application you need:

  • a base class (abstract or not) from a library
  • a library that provides a class that inherits from the base class

In the base class you should declare the signature of the the factory for your derived classes. For example, if your base class is called Foo and you want to instantiate the derived classes with one std::string argument, you can write something like:

#include <PM4hep/PluginManager.h>
#include <string>
class Foo {
  typedef PM4hep::PluginManager::Factory<Foo*, const std::string&> Factory;

  /// Constructor
  Foo(const std::string& name);

  // ...

The templated class PM4hep::PluginManager::Factory takes as first template argument the return type of the factory and as following arguments the arguments required by the constructor of the factory.

The plug-in class Bar defined in the dynamically loaded library will require a declaration to the Plugin Service to use it, so in the source file you have to have something like:

#include "Bar.h"

The library with Foo and the library with Bar will have to be linked against the library

To enable the automatic discovery of plugins, the library with Bar must be processed by the program listcomponents and the output must be stored in a file with extension .comonents in a directory in the LD_LIBRARY_PATH. For example, if the lib directory contains and it is specified in the LD_LIBRARY_PATH, you can call the commands:

listcomponents -o lib/MyApp.components

Note that the .components file does not need to be in the same directory as

The application code, linked against the library providing Foo can now instantiate objects of class Bar like this:

#include "Foo.h"

// ...
Foo* myBar = Foo::Factory::create("Bar", "myBar");
// ...

where the first argument to the function create is the name of the class you want to instantiate, and the other arguments are passed to the constructor of the class.

Special cases

Factory aliases

Together with the simple usage described above, the PM4hep Plugin Service allows you to give to use aliases to refer to the plug-in class. For example, for a templated plug-in class you may have:

#include "TemplatedBar.h"
typedef TemplatedBar<int, std::vector<double> > MyBar;

but to instantiate it you must call

Foo* b = Foo::Factory::create("TemplatedBar<int, std::vector<double> >",

Which is error prone and unreadable, but you can declare the component class with and id (an alias):


(note that the id must support the << operator of std::ostream). The call in the application becomes:

Foo* b = Foo::Factory::create("MyBar", "MyTemplatedBar");


You cannot use namespace delimiters in the call to DECLARE_COMPONENT, but you can still use namespaces for you component classes. For example, if you have the class Baz::Fun you can declare it as a component class in any of the following ways:

using Baz::Fun;

namespace Baz {

typedef Baz::Fun BF;

In all cases the name of the factory to be passed to the create function will be "Baz::Fun".


Simple plugin manager for HEP







No packages published


  • C++ 77.1%
  • Python 9.6%
  • CMake 8.7%
  • C 4.6%