C++ – In C++, how to call an ‘init’ routine as a class is loaded

cclassconfigurationinitialization

I have a program that loads a bunch of "addons" (different meters that measure and display system values).

The "addons" have "grown" over time and the code of what addons to "activate",
and how many of each (if there is more than one of the "device" in the
system (cpu's, net-interfaces, etc) is hard-coded into the master. Ug
(and ick).

What I want is for each addon-meter to place it's name and init-routine-addr
into an array as they are loaded. Right now, what meters that are loaded
are fixed in the master at compile time. What I want is for the possibility
of dynamic loading, but more importantly, for external "script-extensions"
(that could measure "almost anything" and rely on the master to display
the collected data (like a script that would read outdoor temperature via
some 3rd party device). In other words — long after the master has been
compiled, I want to provide the ability for other addon meters to be added
as long as they supply a specific callable API.

Thus, as a new extension is added, I need some init routine to be called
as it loads that will place the new meter-name and routine to be called
in a class-singleton that has an array of the extension names and
their init-routine addresses (as in a dynamically loaded extension).

Then when execution starts, each extension will already have have "registered"
itself with a central list that the "master" can look at and know what
to call.

In Perl, I've used something in a "BEGIN{…} block" in loaded extensions
to call a Plug_Common->register("plugin name", \%Plugin_Description_Data); so when the main routine started it would look in the plugin-registry to see
what was available, dynamically, at runtime.

The question is, how do I do this in C++?

I've setup register routine, but I've no idea how to have the extensions
get their "name & address" registered before the main-master runs. Theoretically, since some of the extensions could be added via scripts long after the main-master was written — it wouldn't be able to know their names in advance.

Off the top of my head, I can only think of a "user-edited" static text file, that might be able to have the master, "somehow(?!)" call each extensions init and 'get_config' routine. Then I can get rid of all the 'extension/meter-specific'-knowledge out of the the master. I don't like the text-file idea as it's too prone to user-error — having something being able to automatically call a register-function as it is loaded, seems much less likely to have problems like the static-config file being out-of-sync with what extensions can be used on the system.

Any ideas? (I'd rather not have to build in a copy of something like Perl to handle the dynamic "loadability" of modules…to me, that would be 'ugly'…

Seem a bit unreliable for the master program to try to look through some
symbol table at runtime — especially with C++'s strong typing. I keep coming up with flaws in virtually every method I think of. :-(. Anyone know a better way? ;-)…

Update:
Had a thought (well more than one, but this one is a bit unconventional, but might work) What if each of the plugins declared a shared pointer to a global list in the master?) If the shared pointers were used in module level inits, then wouldn't the shared 'use count' be incremented as the modules were loaded?…hmmm… I don't know yet how to get the modules' addresses into the main array (without them getting any execution time), but if I can figure out a way for an initializer statement using the shared_ptr, then since loading it a non-multithreaded (at least at this point) if that pointer could be leveraged to increment and store the address of an init function, in a global array, that might give me my dynamic config? Right now, the only thing I know for sure is that shared pointers do have an accessible 'use_count' — which would only help me in determining how many plugins had registered. Maybe there is no way to make this work, but just a thought (at 5:45am after I've been up all night… so, may be completely flawed and I just don't see it yet…;-))… Anyway, thought I'd add my latest thoughts; For scripts I'm thinking of splitting off that type of plugin into a separate handler that would have to read some config… I don't really like it, but it does isolate those things that wouldn't load @ program start time… Anyone think it is possible to leverage the shared-pointer to do this?

Best Answer

In most plugin systems in C and C++, the loading of plugins works like this:

The main application specifies a path where the plugins should be located (or allows such a path to be configured). On startup, the application looks for either dynamically loadable libraries (DLLs on Windows, .so on Linux, in case of compiled plugins) or scripts (in case of interpreted/scripted plugins) in the plugin path.
For each plugin that it finds, the application tries to call an init/registration function that allows the plugin to register itself with the application. For interpreted/scripted plugins, this could be the main body of the script.

To support interpreted/scripted plugins, the application needs to incorporate a scripting engine that understands the language that the plugin is written in.

When writing a compiled plugin, one of the rules is that you build it as a dynamically loadable library and that you provide the initialization function with the exact name and signature that the main application expects.
Furthermore, any classes that the plugin provides must be derived from an interface specified by the main application for plugins that provide a certain service.

For a scripted plugin, the requirement is that the initialization function performs the initializations and registrations that are expected by the main application.

Related Solutions

C++ – Syntax of passing lambda

Your main problem appears to be that your design makes your classes know too much about each other, which will give you headaches with cyclic dependencies and inextricable ownership issues – especially since you're apparently using raw pointers a lot.

Your Task abstraction shouldn't know anything about Meter, or if it does, it should know about an abstract base class for your meters, and rely exclusively on that. And Meter should be completely oblivious of the Task system. This will enable you to have a task and scheduler abstraction that are either completely generic, or only depend on a well-defined interface.

You state in comments that going with an abstract base class and virtual methods would be too heavy, so a "generic" task abstraction should be the way to go. Tools to build that in C++ would either be templates, or in this case using a std::function to hide the actual type (and "nature") of the task to be run.

Here's a minimal task setup, you'll need to add your task state (enabled/disabled, next start time, etc.) in there, and adapt your scheduler to use this: (see How can I store a lambda expression as a field of a class in C++11?)

#include <functional>

struct Task
{
    Task(std::function<bool()> f): func(f) {}
    bool execute()
    {
        return func();
    }
private:
    std::function<bool()> func;
};

You can use this utility to schedule ordinary functions, or lambdas – std::function takes care of hiding the actual type of the callable it handles for you.

Example usage:

#include <iostream>
#include <vector>

#include "task.h"

bool foo()
{
    std::cout << "Fooing" << std::endl;
    return true;
}

struct Meter
{
    Meter(std::string n): name(n) {}
    bool process_events()
    {
        std::cout << "Processing " << name << std::endl;
        return true;
    }
private:
    std::string name;
};

int main()
{
    Meter m { "CPU" };
    std::vector<Task> tasks;
    tasks.emplace_back(foo);
    tasks.emplace_back([&m](){return m.process_events();});

    for (auto& task: tasks)
        task.execute();
}

Now this looks wrong:

class XOSView : public XWin, public Scheduler { ... };

A window isn't a scheduler, a scheduler isn't a window, and a game isn't either of those either. That sort of construct is will give you more headaches going further than you already have. Use composition. Your game should have a UI, and have a scheduler, and a bunch of other stuff. It shouldn't be a UI and a scheduler at the same time.

_xos->sched_insert(t);

Transform that to use a member scheduler object:

_xos->sched().insert(t);

Then figure out whether your meters need to know about the game controller or the UI. If they need both (what I understand from your comment), pass a reference to both during construction until the time you can make a better interface between those.

Multiple inheritance is very easy to get wrong, even more so than plain inheritance (which is difficult enough already). Avoid it unless you know better.

Random advice:

Make sure you understand the difference between a class declaration and definition, and what you can do with an incomplete type (on that has been declared but not defined). See for example Does not name a type error in C++, and for more info When can I use a forward declaration?.
Don't try and bypass a type error with a void*. Understand your problem and fix it. Types are central to C++, and void* is as close as to a "non-type" as possible. The compiler can't help you with it, can't warn you about type errors when you use that.
Be more careful with your syntax. If t is a pointer t.foo() is wrong. This isn't Java. Classes and struct definitions must end with a ; (struct foo {};). Forgetting that semicolon will lead you to very bizarre compiler errors.
Don't use new, this isn't Java. Use std::shared_ptr and/or std::unique_ptr with their std::make_shared/std::make_unique helpers. This will same you a lot of memory management issues, and exception-safety gotchas.
More reading on lambdas: What is a lambda expression in C++11?, Lambda Expressions

Best Answer

Related Solutions

C++ – Syntax of passing lambda

Related Topic