C++: Dynamically loading classes from dlls

Question

For my current project I want to be able to load some classes from a dll (which is not always the same, and may not even exist when my app is compiled). There may also be several alternative dll's for a given class (eg an implementation for Direct3D9 and one for OpenGL), but only one of the dlls will be loaded/used at any one time.

I have a set of base classes that define the interface plus some basic methods/members (ie the ones for refrence counting) of the classes I want to load, which the dll projects then derive from when creating there classes.

//in namespace base class Sprite : public RefCounted//void AddRef(), void Release() and unsigned refCnt { public:     virtual base::Texture *GetTexture()=0;     virtual unsigned GetWidth()=0;     virtual unsigned GetHeight()=0;     virtual float GetCentreX()=0;     virtual float GetCentreY()=0;     virtual void SetCentre(float x, float y)=0;      virtual void Draw(float x, float y)=0;     virtual void Draw(float x, float y, float angle)=0;     virtual void Draw(float x, float y, float scaleX, flota scaleY)=0;     virtual void Draw(float x, float y, float scaleX, flota scaleY, float angle)=0; }; 

The thing is I'm not sure how to do it all so that the executable and other dlls can load and use these classes since ive only ever used dlls where there was only one dll and I could have the Visual Studio linker sort it all out using the .lib file I get when compileing dll's.

I dont mind using factory methods for instancing the classes, many of them do already by design (Ie a sprite class is created by the main Graphics class, eg Graphics->CreateSpriteFromTexture(base::Texture*)

EDIT: When I needed to write some c++ dlls for use in python I used a library called pyCxx. The resulting dll basicly only exported one method, which created an instance of the "Module" class, which could then contain factory methods to create other classes etc.

The resulting dll could be imported in python just with "import [dllname]".

//dll compiled as cpputill.pyd extern "C" void initcpputill()//only exported method {     static CppUtill* cpputill = new CppUtill; }  class CppUtill : public Py::ExtensionModule<CppUtill> { public:     CppUtill()     : Py::ExtensionModule<CppUtill>("cpputill")     {         ExampleClass::init_type();          add_varargs_method("ExampleClass",&CppUtill::ExampleClassFactory, "ExampleClass(), create instance of ExampleClass");         add_varargs_method("HelloWorld",  &CppUtill::HelloWorld,  "HelloWorld(), print Hello World to console");          initialize("C Plus Plus module");     } ... class ExampleClass ...     static void init_type()     {         behaviors().name("ExampleClass");         behaviors().doc ("example class");         behaviors().supportGetattr();         add_varargs_method("Random", &ExampleClass::Random, "Random(), get float in range 0<=x<1");     } 

How exactly does that work, and could I use it in a purely c++ enviroment to solve my problem here?

Answer 1

Easiest way to do this, IMHO, is to have a simple C function that returns a pointer to an interface described elsewhere. Then your app, can call all of the functions of that interface, without actually knowing what class it is using.

Edit: Here's a simple example.

In your main app code, you create a header for the interface:

class IModule { public:     virtual ~IModule(); // <= important!     virtual void doStuff() = 0; }; 

Main app is coded to use the interface above, without any details on the actual implementation of the interface.

class ActualModule: public IModule { /* implementation */ }; 

Now, the modules - the DLL's have the actual implementations of that interface, and those classes don't even have to be exported - __declspec (dllexport) isn't needed. The only requirement for the modules is to export a single function, that would create and return an implementation of the interface:

__declspec (dllexport) IModule* CreateModule() {     // call the constructor of the actual implementation     IModule * module = new ActualModule();     // return the created function     return module; } 

note: error checking left out - you'd usually want to check, if new returned the correct pointer and you should protect yourself from the exceptions that might be thrown in the constructor of the ActualModule class.

Then, in your main app, all you need is to simply load the module (LoadLibrary function) and find the function CreateModule (GetProcAddr function). Then, you use the class through the interface.

Edit 2: your RefCount (base class of the interface), can be implemented in (and exported from) the main app. Then all your module would need to link to the lib file of the main app (yes! EXE files can have LIB files just like DLL files!) And that should be enough.

Answer 2

You are re-inventing COM. Your RefCounted class is IUnknown. Your abstract class is an interface. A COM server in a DLL has an entrypoint named DllGetClassObject(), it is a class factory. There is lots of documentation available from Microsoft on COM, poke around a bit to see how they did it.