how to return the address of a member of a class

Hi, this is just a quick one which i couldnt find any examples off, and my test program doesnt want to compile no matter what i try, but im sure someone must know the answer.

i have a class in a dll, and i want to return that classes constructor to the main program and call the constructor from there, because im using dynamic linking and one of the argument types is not defined in the dll. My question is how do i get the address of the constructor, and once i have it can i just consider it to be a void function. When i say get the address, i will have a c function within the dll which gets the address and return it, not using getprocaddress. Thanks.

Quote:

---

Originally Posted by *DEAD*

Hi, this is just a quick one which i couldnt find any examples off, and my test program doesnt want to compile no matter what i try, but im sure someone must know the answer.

i have a class in a dll, and i want to return that classes constructor to the main program and call the constructor from there, because im using dynamic linking and one of the argument types is not defined in the dll. My question is how do i get the address of the constructor, and once i have it can i just consider it to be a void function. When i say get the address, i will have a c function within the dll which gets the address and return it, not using getprocaddress. Thanks.

---

you have 2 possibilities:

1. the "active" method:


you add something link this to your implementation file of the future dll.
this function takes the agruments to the ctor of your class (ignore mine here), creates on object on the heap and returns a handle.

in your main program you just get the address of that function (getProcAdress()) and save it. Than you can use it to create your objects.

Code:

---

extern "C"
{

       
shared_ptr<Entity> maker(const int id, PrioQueue& prioQueue, tPrioSet prio)
{
        shared_ptr<Entity> entity(new FennekEntity(id, prioQueue, prio));
        return entity;
}



} // extern "C"

---

2. the "passive" method:

Code:

---

// .h file of dll



class Proxy
{
       
public:

        Proxy();
};





// .cpp file of the dll



extern "C"
{


shared_ptr<Entity> maker(const int id, PrioQueue& prioQueue, tPrioSet prio)
{
        shared_ptr<Entity> entity(new FennekEntity(id, prioQueue, prio));
        return entity;
}

       
Proxy::Proxy()
{
        dem::EntityManager::instance().registerEntityType("FENNEK", &dem::maker);
}

} // extern "C"


namespace
// anonymous namespace to make the global
// invisible to other translation units
{

Proxy p;  // calls the Proxy-CTOR

} // anonymous namespace

---

here you just have to open the dll (LoadLibrary() ), the object p is created what calls back into you main application a function what saves the address of maker and the type of dll. (can be simplified if you just have one dll and no inheritance hierarchy in it)



but beware:

depending on you compiler you have to use import/export macros in front of the exported functions in the dll sources. in the case of minGW there are compiler options to export all symbols (no need for macros then).

the most tricky thing is needed while you are saying

Quote:

---

because im using dynamic linking and one of the argument types is not defined in the dll.

---

because of that (at least under windows) you'll have to build build your main program what should load the dll later first and link it then (or its import lib) to the dll source files.


get deeper informations from here:

http://www.nabble.com/Generic-DLL-qu....html#a1319075



an example for use of import/export macros is here:

http://www.mingw.org/MinGWiki/index.php/sample%20DLL
http://209.85.129.104/search?q=cache...lnk&cd=3&gl=de

some general examples:

http://www.codemaestro.com/articles/...e00000001.html

thanks for the reply
Im not entirely sure what this line of code means. Is dem and "FENNEK" something you defined or is that some sort of standard cpp library.

Code:

---

        dem::EntityManager::instance().registerEntityType("FENNEK", &dem::maker);

---

anyway before i implement one of those solutions id just like to make sure of one thing, as I understand it there is no way to define a class, whos structure is unknown at compile time, from a dll into the main program using dynamic loading. Is this correct?

Quote:

---

Originally Posted by *DEAD*

Code:

---

        dem::EntityManager::instance().registerEntityType("FENNEK", &dem::maker);

---

---

the register function just inserts to a std::map a string that describes the dll whos maker function pointer is given.
for example: you have a program and wants to build a plug-in structure to vary the user interface. you have 2 dll's: one with the standard interface and one with a really fancy colored one. now at program start you lookup the plugin directory, find 2 dll's, call LoadLibrary() on them and they automatically call your register function in the main app like this:
appObject.registerGuiPlugin("standard", &maker); and the second one
appObject.registerGuiPlugin("fancy", &maker);

now somethere else you want to display the gui like this:
1. string guiType = read config file ore evironment dir to get the type of GUI the user prefers
2.buildGui( guiPluginRegistryMap[guiType](params_to_ctor) );

thats the way plugins work: you decide at runtime what typ you want and load the proper code from a dll.

Quote:

---

Originally Posted by *DEAD*

anyway before i implement one of those solutions id just like to make sure of one thing, as I understand it there is no way to define a class, whos structure is unknown at compile time, from a dll into the main program using dynamic loading. Is this correct?

---

yes I guess so. To use an object of a class you need to know it's public interface. How would you do anything with it otherwise? In the case of pluggable GUIs you want to have a generalized GUI base class holding all pure virtual interface functions which are implemented in your gui dll's. That base class is known to the main app

If you describe your exact problem I maybe can help you in a more specific manner

wow, thats almost the exact problem im having. Im building a plugin interface using wxWidgets. The problem is that the dll refuses to spawn a window, even a simple window thats doesnt have a parent. It seems to be a bug with the mingw compiler or wxWidgets. Anyway, as a work around i thought maybe if i could call the constructor from within the main program itself, i might be able to get it to work. Your example is pretty similar to what im doing, so hopefully i can get it to work.

what parts of the gui should your dll's include? A class that extends wxFrame (the parent window)?

btw wxWidgets has a portable class to handle dll-loading so you do not need the plattform specific LoadLibrary() or dlopen() on linux

http://www.wxwidgets.org/manuals/sta...dynamiclibrary

the hope was to have a core function which which basically used getProcAddress (yes i was pretty annoyed when i found the dynamic library class, but im not going to change what works) to get the pointer to any function in any dll. When each dll is initialized, the address of this function is passed to the dll and it is then able to call it, allowing it to communicate with all the other dlls as long as their functions are documented. My hope was to start a project which anyone could work on using any compiler what so ever, because i was put off working on a similar project because, whilst it was open source, required the MFC which im not going to either pay the $700 or bother downloading, to compile the "SDK" for the program, which had all the functions one might need to make a plugin useful. This method of communication I figured might have a chance allowing anyone to work on it because there are no dependencies. Anyway i got it working using a hello world type test, and now i want the programmer of the dll to be able to spawn a control frame for their code, else wise their code would be kinda useless. Then came a little paradox. I could either create the frame within the dll or the main program. Assume mainFrm is the frame class for the main program, and dllFrm is the dll's.

Code:

---

dllFrm * dllFrame;
DLLIMPORT void createFrame(mainFrm * parent)
{
    dllFrame = new dllFrm(parent, wxID_ANY);
}

---

However mainFrm is not defined in the dll. Likewise, if i were to try return a pointer to a dllFrm, dllFrm wouldnt be defined in the main program. So i thought that if i could define the dllFrm class in the dll, and call its constructor from within the main program, there might be a chance it could work.

Right now, im almost willing to put up with anything that works. I dont care if the spawned window doesnt have a parent because i have the other method of communicating with the dll, but i cant even get that to work. Well thats the problem with as much detail as i can possibly describe. Thanks for the help so far.

EDIT: one last thing just to emphasize that last point. I cant even spawn a wxMessageBox from within the dll, and im pretty sure i cant possibly stuff that one up.

Another question, im just readin up on how virtual functions work to be honest ive never need to use them before. Because dllFrm is derived from wxFrame which is derived from wxWindow, would i be able to use that as a base class. For example in the dll have something like

Code:

---

dllFrm * dllFrame;
DLLIMPORT wxWindow * getFrame(wxWindow * parent)
{
    dllFrame = new dllFrm(parent,wxID_ANY);
    return dllFrame;
}

---

which receives and returns a mainFrm and dllFrm respectively, but are treated like wxWindows, or would all the functions in the derived class have to be defined as virtual.