What do people here know about making dll files to export some functions and code and things? I am thinking about making some (a lot) of my rendering pipeline and model classes and stuff into a dll file to simplify some of my coding, but I am not sure how they work, especially in conjuction with openGL Can DLLs store classes and stuff like that? If I were to make a model class in a dll, can I then create and access the class structure from functions inside the dll? I think that the executable hosting the dll can only interact with it via global functions (am I wrong), however could those global functions maybe reference class variables and member functions defined within the dll? what about defined in the executable? One more thing... What about library calls, such as OpenGL and FMOD.... Assuming that the executable already has a rendering context defined, will OpenGL runtime calls from the dll behave as the are supposed to? I never really bothered to learn about dlls, so I wanted to know if someone could help me out here... -------------------------------------- It took me long enough, but now I am finally 16. Yay! Sorta funny, but I am probably the only person on earth who wrote a 3D driving game prior to actually driving .

Check this gametutorials for dll using


Good Luck

quote: Original post by Steve132
What do people here know about making dll files to export some functions and code and things?

Right now, I experimented a little with those things. Only on linux however.

quote: Original post by Steve132
...Can DLLs store classes and stuff like that? If I were to make a model class in a dll, can I then create and access the class structure from functions inside the dll?

If you mean ''class'' as a C++ programmer would mean then there are very bad news.
You probably know that C is somewhat less complicated than C++. This means C++ compilers are more complicated than C compilers. When dynamic linking is involved, everything becomes **much** more complicated.
This means that, most C++ compilers are still lacking support to generate "C++ runtime libraries". Even if they would be fully implemented, the way runtime libraries work won''t allow you to store a whole class so easily unless you do some tricks.
The main problem comes from overloading.
void DoSomething();
void DoSomething(float parameter);
int DoSomething(float *pointer);

In C, the first entrypoint would be called
DoSomething() {text}
Or something compiler dependant.
The second and third things is not valid. C does not allow overloading (as far as I know but I''m all but good at plain C).
Actually, C+++ mangles function names so it becomes more like:
_DoSomething(void) {text}
_DoSomething(float) {text}
_Z9DoSomething(float*) {text}

Uh-oh. Look at how much ugly those things are.
So, say you want to fetch a function from a library... you would have to specify the mangled names (which are probably compiler-dependant, i''m not sure).

This for a **global function**, not to mention how it would be for a "contained" member function.
An extra problem here is that the runtime linking (At least on linux) is C-fashioned and pointer-driven. You actually do something like:
pointerToFunc = RuntimeLink(library, "FunctionNameInC");
I guess you won''t be able to do that for function members unless they are pointers to function which means you have to expose the virtual function table, which makes everything **very ugly**.

So, the idea was to add to C++ an "export" keyword. I has been told it was only recently introduced.
Basically, how to make a nice entrypoint in C++?
extern "C" {
// C thing here, so nice entripoints
// But no C++ nice features!
}
The keyword would avoid using C. As far as I know it would just bypass the name mangling scheme.
Problems: how are namespaces and member functions handled?

Actually, the very difficult thing which is preventing this from being implemented is templating. I tried to research something on that but I wasn''t able to find any useful info... compiler designers are in charge here.

quote: Original post by Steve132
I think that the executable hosting the dll can only interact with it via global functions (am I wrong), however could those global functions maybe reference class variables and member functions defined within the dll? what about defined in the executable?

I guess executables could be loaded just like dlls are... provided they''re position-independant (usually they are not), but i''m not sure.
Many answers can be inferred from the above discussion.

quote: Original post by Steve132
One more thing... What about library calls, such as OpenGL and FMOD.... Assuming that the executable already has a rendering context defined, will OpenGL runtime calls from the dll behave as the are supposed to?

I don''t see why they shouldn''t. I''m missing something here.

Is it possible to return a base class from a dll exported "Create" function and call base methods which are overloaded in the dll? Something like:

CBase *base = (CBase *)DLL_Exported_Create( basic parameters);
base->Render(); //Overloaded in dll

where the create return void *?
Or do you get the same problems as discussed above with code position and such?

Anyway, if not, something like the class that encapsulates a bunch of function pointers like that talked about previously could be done pretty easily I suppose.

Yes, that's perfectly feasable. You could also have a COM-style system where all your classes thay you are exporting implement a certain interface such as:

class IInterface{protected:     virtual ~IInterface(){}public:     bool Release() = 0;     IInterface * CreateReference() = 0;};  

Note: I didn't test that code. It was merely an example. One thing you need to watch out for if you just have a exported function creating a instance of a class, and thus allocating memory, is different C/C++ runtimes being used. You may have problems, kinda like if you try to free something that has been new'ed. With a COM-Style system you don't have to worry about that because the object free's itself.

EDIT: Clarification. COM-Style system objects would free themselfs after Release has been called and the reference count is 0. :-)

[edited by - cilcoder on June 8, 2004 3:40:14 PM]

You can check out this thread for a cross-compiler compatible way of exporting classes from dlls without having to use full COM. Unfortunately my web hosting is currently down, so the zip file I posted is not currently available. If you want it, post your e-mail address and I''ll send it to you.

Enigma

Oh yeah, I forgot it''s a good idea to specify a calling convention for your methods to be cross-compiler compatible. I was reminded by Enigma''s link.

quote: Original post by variant
...Or do you get the same problems as discussed above with code position and such?

Not sure about the problems you are referring here.

quote: Original post by variant
Anyway, if not, something like the class that encapsulates a bunch of function pointers like that talked about previously could be done pretty easily I suppose.

Most of the time, yes, it can be done pretty easily but I would hate have it in my code. I recognize it's a matter of personal opinion however.

quote: Original post by cilcoder
Note: I didn't test that code. It was merely an example.

Maybe could you tell us how do you fetch the entrypoints without having the compiler issue errors?

int func() { return 1;} 

As far as I know the compiler will bail out if I do

func = ipoteticalFetchFromLibraryCall(...);  

quote: Original post by Enigma
You can check out this thread for a cross-compiler compatible way of exporting classes from dlls without having to use full COM.

I'm not sure of what this means but I think this problem is bigger than the one we are discussing here. I'm not sure it's good to introduce that problems for now.

EDIT: small layout improvement.


[edited by - Krohm on June 11, 2004 4:46:45 PM]

In VC++, when you create a DLL, you also get a LIB (I''m not sure about other compilers). You can link that LIB to your program and be able to access the DLL functions by their name:

int DLLFunction();

DLLFunction();

Instead of getting procedure addresses from the library file. If you need to ''dynamically'' load the DLL at various points along your program, this may not help.


-- Fyhuang, president, Altitude Technologies

Altitude Technologies: http://www.hytetech.com/altitude
Altitude Forums: http://s8.invisionfree.com/Altitude_Forums/

quote: Original post by Krohm

quote: Original post by variant
...Or do you get the same problems as discussed above with code position and such?

Not sure about the problems you are referring here.

I guess I mean correct entry points. It will probably compile, but in runtime, will calling the inherited methods correctly reference the dll code, or will it call the base classes implementation?

[edited by - variant on June 11, 2004 5:49:21 PM]