🔒 Locked

Dynamic Class Loader for Shared Libraries

Started by neurokaotix May 27, 2003 at 1:19 AM 3 replies 300+ views

Original Post

May 27, 2003 at 1:19 AM

For my current project I''ve been working on a "dynamic class loader." This is basically a system for which I will *only* need the target DLL/SO to get full functionality of all the classes inside it. Usually you would need a .lib file as well but I don''t want to use one. What my system does thus far is load the .dll/.so, search for an init function which passes a specific class pointers to the mCore and mClass (an empty class which acts as a shell for new classes retrieved from dlls) classes. Then the system searches for a new_pointer function and that function returns a pointer to the classes which I want inside the shared library. So far I''ve gotten the init function to work correctly, it''s a bool so it returns a true or a false (which I''ve tested, so I know that it does in fact retrieve the function and run it). Now I need to figure out how to take the pointer to the newly retieved class and be able to access the functions within it. Let''s say the pointer I got from new_pointer() is called myPointer. I want to do something like myPointer->MyFunction(); but myPointer (which is an mClass*), doesn''t have MyFunction() in it because MyFunction() exists in MyDLL.dll. Which leads me to my question, how can I access these functions from the pointer if they don''t exist? I can''t compile it with the assumption that there will be that function when I try to call it, because you get errors when you do that. Do I maybe need some way to add all of the functions within the class to a list of some sort? This is where I''ve absolutely gotten stuck :\ James Simmons MindEngine Development http://medev.sourceforge.net

paulc

May 27, 2003 at 4:21 AM

The only way I can think to get even slightly close to what you want to do is to have the class in the dll derived from a class in the main app. The class in the main app can be an abstract base class that just defines the interface for derived classes.

There is no way I can think of that will allow an app to call functions off a class instance pointer that the app doesn''t know about, e.g. aren''t included in a header. The app needs to know what the parameters of the function are and where it is in the application in memory terms. Theres a very very small chance that something with member function pointers might work, but it will be very very nasty and with dll memory alloc/de-alloc stuff on top will leave you in a puddle of woe.

Design your app using abstract base classes with virtual functions and everything will be much easier.

sbennett

May 27, 2003 at 4:43 AM

You could try doing something like IDispatch does, but it wouldn''t be very nice.

Specifically, have a single Invoke() method exposed that takes the name of a method to call, and calls it.

neurokaotix

May 27, 2003 at 8:44 AM

Hmm... I know that I can''t have virtual functions because the point of the system is that I don''t need to know what is in the dll beforehand, other than the init and new_pointer functions for each class. I checked out IDispatch and Invoke() and I don''t think they suit my needs... Perhaps I can create some sort of shell for incoming functions and add them to a doubly linked list or something so that I can call them later on. Boy am I lost lol

James Simmons
MindEngine Development
http://medev.sourceforge.net

fizban75

May 27, 2003 at 9:05 AM

Listen, you need to know something about the DLL beforehand in order to use it. When you load a function dynamically from the DLL, you have to specify the function signature somewhere so that the program knows what to look for when it loads it. The same thing holds with a dynamically loaded class. You need to specify the class signature (including any functions on it you are interested in) in order to use it. The best way to do this is to create a virtual base class that exposes some interfaces and then derive all your DLL classes from this base class. Then, you''re application will just get a pointer to this base class from the DLL and go about its merry way calling the methods where appropriate. If the DLL doesn''t implement every function, that''s okay, as long as you''re prepared to handle it. And if your application becomes interested in more interfaces, then you just add them to the base class and then override them in your DLLs when necessary.

To repeat, you have to know the signature of what''s in the DLL in order to use it.

Topic Locked

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