DLL's and inheritence
Author
I''d like to create a factory of sorts where the concrete implementations are located in DLL''s.
(psudo)_
class CRenderer
static CRenderer* CreateObject(type)
in Renderer.cpp
CRenderer* CRenderer::CreateObject(type)
{
switch(types)
OPENGL
LoadLibrary
addr = GetprocAddress
return new addr
DIRECT3D
PS : the DLL has a class called CRenderer that COpenGLRenderer inherits from.
~well something like that...
The goal is to only load the renderer that will be used. I''m not sure however about how to dpo a getprocaddress on a class. I''ve worked with functions. Are classes any different.
Is this even possible? I''ve VERY light on DLL experience, I''ve just finished the whole MSDN chapter on the subject but that didn''t help. Any pointers? Tutorial or sample you could point out?
Many thanks
Chris
Make an abstract base class to specify the interface, and place that header in both the EXE and any DLLs you wish to make. For each DLL, derive from the abstract base class, and implement the methods.
Place the following code in each DLL, using the same name and format:
Then at run-time, load the DLL of choice using LoadLibrary/FreeLibrary, and call those two functions from the DLL using GetProcAddress. (You''ll have to cast the return value of GetProcAddress to the proper function pointer type.) Those methods manage an instance of the derived class which you can then use via the abstract base w/ virtual functions.
Example:
That''s all there is to it... I have wrapped all the messy Windows code and casting inside a class just to make the code cleaner.
Good Luck,
- null_pointer
Place the following code in each DLL, using the same name and format:
extern "C" {
base* allocate() { return new derived; }
deallocate(base* p) { delete p; }
};
Then at run-time, load the DLL of choice using LoadLibrary/FreeLibrary, and call those two functions from the DLL using GetProcAddress. (You''ll have to cast the return value of GetProcAddress to the proper function pointer type.) Those methods manage an instance of the derived class which you can then use via the abstract base w/ virtual functions.
Example:
typedef base* (* allocate_type)();
typedef void (* deallocate_type)(base*);
// Load the DLL into memory
HMODULE hDLL = LoadLibrary("Sample");
// Manually link the functions
allocate_type allocate = reinterpret_cast<allocate_type>(GetProcAddress(hDLL, "allocate"));
deallocate_type deallocate = reinterpret_cast<deallocate_type>(GetProcAddress(hDLL, "deallocate");
// Create an instance of some unknown derived class
base* p = allocate();
p->function1();
p->function2();
deallocate(p);
p = 0;
// Unlink the functions
allocate = 0;
deallocate = 0;
// Unload the DLL
FreeLibrary(hDLL);
That''s all there is to it... I have wrapped all the messy Windows code and casting inside a class just to make the code cleaner.
Good Luck,
- null_pointer
Author
Thanks all, this looks good, the base of this system I already have in place (the class defined in the exe\dll then derived from in the dll.
I wouldn''t be able to use com as the engine is geared towards platform independence.
Thanks
Chris
I wouldn''t be able to use com as the engine is geared towards platform independence.
Thanks
Chris
that COM is platform dependent is a myth.
COM can be reproduced on any platform. I''m sure it already has been reproduced on many of them. It''s a spec.
COM can be reproduced on any platform. I''m sure it already has been reproduced on many of them. It''s a spec.
The name "DLL" might be Windows-specific, but NOT the concept of a library that loads at run-time. COM for all, my friend.
Author
Thanks all. I have used HawkNL and SDL until recently and they are both libraries that are crossplatform so my term DLL was just to refer to whatever they do on other platforms.
In the past I was a middleware VB programmer who used COM\DCOM\MTS\MSMQ\ADSI so the thought of using something COM like is appealing, however the one part of COM that sucked was all that registry crap. I would have preferred just using COM DLL''s like normal DLL without having to have the registry aware of the physical location of the library. Since VB however I''ve never used anything COM like, just straight monolithic code OR static\load time linked libraries''s.
I''ll have a read around and see if I can come up with some kind of simple COM like interface.
Thanks again.
In the past I was a middleware VB programmer who used COM\DCOM\MTS\MSMQ\ADSI so the thought of using something COM like is appealing, however the one part of COM that sucked was all that registry crap. I would have preferred just using COM DLL''s like normal DLL without having to have the registry aware of the physical location of the library. Since VB however I''ve never used anything COM like, just straight monolithic code OR static\load time linked libraries''s.
I''ll have a read around and see if I can come up with some kind of simple COM like interface.
Thanks again.
Author
Bing!
I get it now. You practically handed it to me on a platter and I didn''t see it. I''ll go give this a try now.
Thanks again guys
cb
I get it now. You practically handed it to me on a platter and I didn''t see it. I''ll go give this a try now.
Thanks again guys
cb
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
