Sign in to follow this  
Hamster

DLL Problems

Recommended Posts

I'm making a stab at DLL's for the first time and just wanted to check something. Is it ok to have an exported base class in which not all of the functions are pure virtual? e.g.
//this is our header, used in both the main exe and the dll
class Exported
{
     virtual void VirtualFunc() = 0;
     void NormalFunc();
};

//this is in the DLL
class DerivedFromExported : public Exported
{
     void VirtualFunc();
};

When linking the DLL I get lots of errors unless I do away with the equivalent of NormalFunc entirely. Was hoping you could tell me if this is completely invalid or if I'm going wrong somewhere else. Thanks in advance for any help John

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Yeah, that's fine. Just make sure you implement your VirtualFunc() somewhere or you will get weird linker errors. If you are using Windows, you might want to do something like this in your header file:

#ifdef MYCLASS_EXPORTS
#define MY_API __declspec(dllexport)
#else
#define MY_API __declspec(dllimport)
#endif

// This class is exported from the retert.dll
class MY_API myClass
{
public:
myClass(void);
int myOtherMethod(void);
};

When building your DLL you will need to make sure you define the pre-processor symbol MYCLASS_EXPORTS either through your makefile / project settings or with a #define somewhere in your implementation.

Hope this helps,

Mr. Creamy

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Hello,
Thanks very much for the reply. Sorry about taking my time to reply myself, but I wanted to make sure I'd made some progress before I went further. My project is now working, but I still think something very weird is going on. I've had a look at the design detailed in "Striving For Graphics API Independence", and can't see that mine is much different, yet I must include a lot of my engine cpp files in the dlls I make in order for anything to work. This seems wrong, but to give a bit of an example: (by the way, I realise that none of this is very useful or effective stuff, I'm still experimenting with concepts a little)


/*this is all engine stuff*/
//IModule.h
class IModule
{
public:
IModule();
virtual ~IModule();

virtual bool Start() = 0;
virtual void Process() = 0;
virtual void Stop() = 0;
};

//IRenderModule.h
class CGraphicsWindow;

class IRenderModule : public IModule
{
public:
IRenderModule();
virtual ~IRenderModule();

bool Start(); //get a window and call InitialiseGraphicsSystem();
void Process(); //call DrawSomething
void Stop(); //call DestroyGraphicsSystem and get rid of the window

protected:
virtual bool InitialiseGraphicsSystem() = 0;
virtual void DrawSomething() = 0;
virtual void DestroyGraphicsSystem() = 0;

CGraphicsWindow *m_ptGraphicsWindow;
};

//--------------------DLL------------------------

class CGLRenderModule : public IRenderModule
{
public:
CGLRenderModule();
~CGLRenderModule();
protected:
bool InitialiseGraphicsSystem();
void DrawSomething();
void DestroyGraphicsSystem();
};



Now, the part that is confusing me. I had thought creating the CGLRenderModule class in the DLL would be exactly equivalent to deriving it from IRenderModule within the game, but that gives lots of linker errors. In fact, in order to get CGLRenderModule to work I have to include all of the following:


#include "IModule.h"
#include "IModule.cpp"
#include "GraphicsWindow.h"
#include "GraphicsWindow.cpp"
#include "IRenderModule.h"
#include "IRenderModule.cpp"

class CGLRenderModule...


I also had to link the dll to additional libraries that the code in those implementations was making use of. Should this really be necessary? It feels like something has gone wrong. Thanks to anyone who can help,

John

Share this post


Link to post
Share on other sites
Be careful with the implemented function in a base class. If you're using the give-me-an-interface-from-the-dll approach you'll get in trouble, if that function does anything that will alloc memory.

You end up with two code blocks that will alloc memory, one from the main app, and one from the dll. If one tries to free the memory of the other you get a nice leak/crash/delayed crash.

The "lowest" base class should really be a true interface, a completely abstract class.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this