Hi !! I am working on a scripting language. I want to be able to create functions that I can call from my scripting language, but which aren''t functions written in the scripting language, but which are located in a C++ class. Until know I used DLLs. With LoadLibrary I can load a library and with GetProcAdress I can get a pointer to the function. This works fine, but I want my engine to be done in C++ with classes, So I need to write each function twice, once as a member function of a class and the other time a function in a DLL, which then calls the member function of the C++ class. I need the same for C++ classes. So I have a string which holds the class and the member functions name. Is there a way to get the adress of a member function by name ???? Phillip

that is an ugly question
first, you need to remember that non static member functions are passed the additional hidden parameter of the this pointer to allow access to data members of the class
also, you have to remember name mangling
i wouldnt suggest direct access
now then, you can make the class a com component
you might be able to fake it into acting like a com component, but that is even uglier
basically, just delegate calls
itll save you time in my inexpert opinion

I''ve been giving this very same idea some thought. The cleverest idea I''ve thought of so far is this:

First of all, I haven''t given thought to using DLLs, so if you are reliant on them, make modifications to this . I suppose that the compiled form of the script retrieved from the script file or whatever still contains the string representation of the name of the class and member function. Make the classes you want the script to have access to inherited from a ''script supported'' base class. This script supported base class would then have a function, that, when passed a string, would identify the member function by that name and return a c++ style member pointer. A pointer to the class and a member pointer can be together used to identify a function the way you want. Of course, you''d have to customize this member identification function for each class supported in the script.

It would be an elegant way of interfacing script code run in a virtual machine with the actual executable code. It''s also close to the only way, since you simply do not have any access to the pointers before run-time, and there is no GetProcAddress-like function available, unless you provide it yourself.

I hope I was clear enough .

Yet another point where Java beats the cr*p out of C++

/Niels

What on earth are you talking about, Niels? Last I checked, Java couldn''t load a class from a DLL either.

If this starts a flame war, I''m going to have to beat the participants about the ears with a slightly thawed halibut. *smile*

Play nice.

-fel

Sorry, if my tone was off, I''m just extremely confused by Niels'' comment. Java can''t put classes in a DLL. Nor does it have a function to return functions by name. It doesn''t even have the capability to return a function pointer. And besides a halibut is very passe. I''d much rather be slapped around by a fresh mackrel.

To actually contribute to the discussion, "Essentials of Prgramming Languages" by Friedman, et al. has a interesting segment about representing classes by data. Potentially you can write a parser for that data in a DLL, and pass references to such data structures rather than C++ classes. It''s very involved though, most likely your better off writing a C++ class that wraps a basic DLL interface and use string constructors for that DLL to load specific data. Then call member functions from the class with a function that accepts a string argument and a void *. However that still doesn''t allow you to install the class in a DLL.

Actually...
Java can return the name of a class, member functions (with arguments needed, and variables included through a nice thing called reflection =)

quote: Original post by Niels

Yet another point where Java beats the cr*p out of C++

/Niels

But alas, it can still be done with C++ if you choose to go that route. Maybe not the sweetest implementation, but implemented none the less