Skip to content

Shared Interface

The Warrior interface is a common C++ abstract class. We’ll need a header file as well as a source file, let it be Warrior.hpp and Warrior.cpp. You can put it wherever you want, just make sure that both projects can access it.

I declared a virtual pure getter for the warrior description, but please, feel free to add the properties and functions you’d like (energy, armor, attack, etc).

class Warrior{
    virtual std::string getDescription() const = 0;

As stated on the introduction, the host will be able to create warriors through warrior providers. So we need a WarriorProvider interface that allows host to create warriors. Fortunately Pluma generates one for us with two macros. One macro generates the class header part, the other generate code for it. That’s why we need a cpp file as well.

On the Warrior.hpp file we write right after our class:


This generates the WarriorProvider class declaration.
Note: The semicolon at the end of the macro is optional.
Don’t forget to include the Pluma header or the macro won’t be recognized.

The Warrior.cpp will contain just the provider source:

#include "Warrior.hpp"

The first argument of the macro PLUMA_PROVIDER_SOURCE is the type of objects we want to provide. The second argument is the current version of the interface, and the last argument is the lowest compatible version. The version arguments are unsigned int values.

Whenever we modify the shared interface, we should increment it’s version. But it may not break with previous versions. For example, if we just add a new function which has a default behavior (a “virtual int attack(){ retunr 0; }” for instance), older plug-ins are still compatible and can be loaded. But if we modify the function “getDescription” to “getName“, older plug-ins won’t be compatible, and so we must modify the lowest compatible version to prevent older versions to be erratically loaded.


You’ve created an interface that will be inherited by plug-ins and used by the host. You also generated the corresponding provider class. From now we can assume the existence of the class WarriorProvider. On the next page we’ll define the plug-in, which will introduce two warrior types and the corresponding providers.

Index || Introduction << Shared Interface >>  Plug-in Side