("Dynamic") Class in DLL

[durbrak]

Hello,
First off, I must admit I have never really worked with DLLs before. Anyway I have a simple (more or less) question regarding those DLLs.
Okay, I have a main program "main.exe" which is the actual application. Now in its source code there's a class "AbstractModule".
Now I want to subclass from this abstract module class to create some real modules for my application and put that subclass into a separate file (i.e. DLL). Let's assume that module is "class TestModule : public AbstractModule" and the DLL is named "test.dll".
My main.exe application now receives a request for the module called "test" (dynamically). It knows that it has therefore to look for the file "test.dll" in the modules directory. Now of course main.exe somehow needs to initialize the module but of course it doesn't know that the actuall class is "TestModule", it only knows that it is a subclass of AbstractModule and for the initialization it only needs some of the virtual functions of AbstractModule.
So basically my problem is to load (dynamically... what I mean by that is that just imagine the user types the word "test" into a QLineEdit and now the application has to load the module "test" from the "test.dll") that subclass and initialize it. As previously said, the class in the test.dll is a subclass of AbstractModule and the main.exe doesn't care how the subclass is named or what it is, it only needs to know that it is of AbstractModule.
So, how do I realize that?

Well, long text but I just wanted to clear everything up
Thank you in advance

[wysota]

Two choices:
1. QLibrary
2. Plugins

[durbrak]

Thanks, I also considered using QLibrary but the documentation only shows how to deal with a library's functions. But I need to resolve the class and since I don't know the class name (I only know that the class is a subclass of "AbstractModule") can I just resolve it by using the AbstractModule type?

[wysota]

If you want to dynamically load a class, you need to have a function in the library which will return an instance of the class (the plugin infrastructure does more or less the same) - it is called a factory function because it is a factory of objects from the library.

extern "C" __declspec(dllexport) AbstractModule *create(){
  return new TestModule();
}

extern "C" __declspec(dllexport) AbstractModule *create(){
  return new TestModule();
}

To copy to clipboard, switch view to plain text mode 

Note that it has to be a function, not a class method and that you have to disable name mangling for it.

[stevey]

Just a point on architecture, don't put the class definitition for AbstractModule in your main code. You should group all your interfaces (abstract classes) into various header files and #include them where needed.
In your case 'TestModule' should #include <{appropriate header}> and so should the main project.
You can still do your dynamic plugin loading, but this model will prevent a circular dependency. Given that your main will have a TestModule, it doesn't make sense for TestModule to need something from main. If they both use somethign from elsewhere, then you're safe.

[durbrak]

Well, I think I already do that the way you said. I put the AbstractModule definitions into the abstractmodule.h and the declaration into abstractmodule.cpp and compiled the abstractmodule into my main program. then I use a separate project "TestModule" and create there my TestModule and simply include abstractmodule.h (without compiling the abstractmodule.cpp into the TestModule).
Is that what you meant ?