🔒 Locked

Class pointers

Started by Galapaegos Apr 20, 2002 at 11:42 PM 8 replies 1.3k views

Original Post

Apr 20, 2002 at 11:42 PM

Hey everyone, Having some problems about how to implement something of this nature. Here is my thought: i am writing a graphics engine and have separate dlls for the rendering api. my thinking is to have an abstract class declared in a header shared shared by all the dlls ( the engine, and the rendering api''s ). Then, in the rendering api''s i would declare the the class with specific operations, etc. But how should i get the class? I would load the lib ( of course! ) first, then could i use GetProcAddress? as if i were calling a function pointer? Thanks for the help! Brad Hittle

IndirectX

Apr 21, 2002 at 12:12 AM

Your question isn''t very clear, but if I understand it correctly, try this:

  
// Common .h file

class Renderer {
	void Render() = 0;
	// and other stuff

};

// .dll .h file

class RendererImpl : public Renderer {
	void Render();
	// and other stuff

};

// .dll .cpp file

__declspec(dllexport) Renderer *CreateRenderer() {
	return new RendererImpl;
}

// client .cpp file

Renderer *(*CreateRenderer)();
HANDLE hDLL = LoadLibrary(renderer_dll_name);
CreateRenderer = GetProcAddress(hDLL, "CreateRenderer");
Renderer *pRendererObject = CreateRenderer();

Hope this helps.

Galapaegos

Author

Galapaegos

Apr 21, 2002 at 12:29 AM

I have no idea about how well this will work, but this is my idea. I''m going to try using COM to implement this. Just to give a better understanding of my dilema, i want to have a *basic* class that contains the operations for the drivers. I want to make the libraries as independent from each other as possible, so that one doesn''t rely on another. Hope that is a better explanation. If there is a simpler way to do this, please inform me ASAP! thanks once again!

Brad Hittle

IndirectX

Apr 21, 2002 at 12:33 AM

Any particular reason to prefer COM over the code I posted? Remember that COM has its overhead and you must write stuff to the registry to use CoCreateInstance. That means you can''t just unzip your game and run .exe file. The code above, however, doesn''t require registration.

Galapaegos

Author

Galapaegos

Apr 21, 2002 at 12:39 AM

I'm sorry, i see what you are talking about now. Your simply saying to have a function within it and use that to create and then point to the class. that makes a lot more sense. Thanks alot. Although i still might try COM just for fun, never hurts to learn new stuff! Thanks again!

[added]: The only problem that i've been having is getting the GetProcAddress to work properly. I have gotten it to work, but once, maybe twice. I my current engine, it does not work ( thus looking for a new idea to try ) and i used the code straight from one of the times it actually worked.

Brad Hittle

[edited by - Galapaegos on April 21, 2002 1:43:23 AM]

IndirectX

Apr 21, 2002 at 12:54 AM

Ahhh, name mangling. There''s an article on organizing code into several files in the refernce section, it might have a solution to this.

Galapaegos

Author

Galapaegos

Apr 21, 2002 at 1:04 AM

well, its not as much name mangling, as something screwy w/ my comp! i''m not that positive, but i do keep my code surprisingly as clean as i can. each class has its own header/source, and i''ve kept the dependencies as low as possible between header files ( my source files have only one #include ). my thinking is that i didn''t export the function i wanted to call correctly. How do you export a function for calling in GetProcAddress, w/ __declspec(dllexport)? What i did was this:

//Common file:
typedef (driver_struct) *(CALLBACK *GetTheDriver)(void);

//Driver dll source
driver_struct *GetDriver( void )
{
//something here
}

//Engine dll source
...
GetTheDriver Func;
hLib = LoadLibrary( ... )
Func = GetProcAddress( hLib, "GetDriver" );
...

That looks correct, doesn''t it?

IndirectX

Apr 21, 2002 at 1:13 AM

Do you know what the dependency viewer is? If you have MSVC, it should be in your Tools start menu folder if you installed it. In any event, its updated version can be downloaded for free on the net. This tool will tell you exact names of the exported and imported functions.

You can eitehr declare and define your exported functions like so:

__declspec(dllexport) extern "C" int __cdecl SomeFunction(void *data);

and using the dependency viewer to determine the actual name by which it''s exported and using that name in GetProcAddress, or you can use DEF files to specify the name that you wish your function to be exported as. I can''t be bothered to look up the DEF file syntax; use MSDN for more info.

Note that you should explicitly specify calling convention for exported/imported functions. You may use __stdcall as well, since it''s a bit faster.

Galapaegos

Author

Galapaegos

Apr 21, 2002 at 10:15 AM

Hey IndirectX,

Got a big question for you. I''ve finally gotten the GetProcAddress function to work, but this is my question. I used the dependency viewer and found the function to be:
"?GetDriver@@YAPAUZEMPAT_DRIVER@@XZ". This won''t be the same if i have the same function only in another library. Shouldn''t i just be able to use the function name rather than a name like the one up above? Thanks once again!

Brad Hittle

IndirectX

Apr 21, 2002 at 10:34 AM

You''re talking about name mangling. Consider two functions:

int Add(int a, int b);
double Add(double a, double b);

If the compiler referred to both functions as "Add" and you tried to GetProcAddress() one of them, how would you know which one you got? Hence, the name mangling: compiler adds some stuff after the function name to distinguish between the overloaded versions. This also allows you to export things such as constructors, destructors, and overloaded operators, which don''t have function names as such.

Use either extern "C" or DEF file to avoid name mangling.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.