Hot-pluggable C++ library possible?

Question

I'm looking to "hot plug" a library of C++ code. I'm interested in having this technique work cross platform between Linux/Mac/Windows. Basically I want to have the main program #include "StateMachine.h" which defines all callable interfaces. Then at runtime and DURING EXECUTION load and unload StateMachineLibrary.a to have my application use different state machines.

One thought I have is maybe do something like write a wrapper that loads this compiled code in to my own malloc'd memory and creates function pointers in to that memory?

Motivation is that the State Machine portions of my project will be frequently changing and need recompilation, also would allow the main app to continue running with different State Machines being loaded. I'm hoping to use a "hot-pluggable" library INSTEAD OF something like Lua scripts due to some concerns, so considering that as an alternative has already been explored.

Answer 1

Define a base interface and derive your implementations from it. Put these into dynamic libraries (DLL/SO) and load them at runtime. The library will just need a static factory function to deliver an instance of its implementation to you.

// shared
class Base {
 public:
   virtual void DoTheWork() = 0;
};

// within the DLL/SO
class Hotplugged : public Base {
  public:
   virtual void DoTheWork() {
      std::cout<<"I got hotplugged!"<<std::endl;
   }
};

extern "C" Base* CreateIt() {
  return new Hotplugged();
} 

// within the app (sample for Windows/MSVC)
... ::LoadLibrary("mydll");
Base* (*fpCreateIt)() = (Base*(*)())::GetProcAddress(... "CreateIt");
// call the function pointer to obtain a Base instance
Base* mybase = fpCreateIt();

// prints the above text
mybase->DoTheWork(); 
delete mybase;

Note: this is just a sketch. It has some flaws, for example I'm ignoring ownership semantics, and no actual checks are done if the DLL we just loaded is binary compatible with us. Think about it a bit, or look for existing implementations (some are mentioned in other responses).

Answer 2

This is possible. For cross-platform work (at least recompile only), you might want to look at some existing frameworks that do this.

OpenSceneGraph includes a full featured, "hot-pluggable" implementation for loading and unloading plugins.

Qt has a plugin framework, as well.

The "trick" is having a clean interface for your plugins, and just using dynamic libraries that can be loaded and unloaded. Nearly every platform (all major ones) support dynamic loading and unloading of libraries, so there is nothing that prevents this from working.

Answer 3

Yes - it's certainly possible. In a previous role where we developed an 3D graphics API and applications we let the user choose the display driver "on the fly". The view had to be recreated, but the application itself didn't need to shut down.

Answer 4

Though many parts of it are quite dated, Advanced C++ Programming Styles and Idioms (James Coplien) has a section on how to do such things that might be useful to read through (though I'm not sure I'd buy a copy just for this).

Answer 5

Check out Boost.Reflection and Boost.Extension - they were designed to address the various issues involved with attempting such things. I'm pretty sure it still doesn't let you work across compilers or versions, but it might be of aid to you.

Answer 6

I wrote v3c-dcom initially just to see if I could do it - you can download it from Sourceforge.
it's basically just a plug-in system at the moment.
It depends on three other SourceForge projects, so you will have to download and install them first.

Go to SourceForge http://sourceforge.net/ and download the following projects:
* v3c
* treedb
* meta-treedb
* v3c-dcom

v3c contains a build system and a general utility library.
treedb contains the core "persistent memory" functionality.
meta-treedb wraps treedb inline implementations in a blanket, shortening compile times and code bloat.
v3c-dcom contains some examples, including creating a plug-in repository inside the program, adding a library to the repository, calling CoCreateInstance() to create objects, and calling methods on those objects.

I designed the build system to be user friendly, even though it's automake based ;)

Just do make && sudo make install in the unpacked directories of each project in turn.

If you're paranoid or don't have "sudo" privileges read v3c's README and the "tryout" script on how to unpack/build/install the packages under a directory you own.

make check will run each library through its paces and for v3c-dcom it will run the demo I mentioned above.

Hope this helps.

Answer 7

And don't forget XPCOM. It's designed to be a cross-platform COM.