Thread: member fn pointer -> fn pointer?

Hi,
the last day i read through things like boost::bind, mem_fun, boost::function and google to find a proper way to pass a member function pointer to a function that takes a c-function pointer.

In my imagination I pass a member function pointer together with an object to some function, and it returns a c-function pointer, with the object address hard coded in it somehow.

Code:

struct A
{
    void mem()
   {}
};


void c_api_function( void(*fn)() )
{
    // do something with fn
}

int main()
{
    A a;
    c_api_function(); // somehow pass &A::f of a
}

so I'm looking for anything that is able to directly pass a's member f to the c-funtion.


nothing I read about seems to do this. I know the workarounds proposed in the c++ faq. but isn't there not a more elegant solution?

The closest thing I found is the thing the first poster mentioned here:
http://groups.google.com/group/comp....52115c6f839238
But I'm not feeling to be at the level of understanding c++ to use that.

Thanks for your ideas!

What you want to do isn't trivial. If you can make your function pointer take an arbitrary pointer as an argument, you could make a pointer to an object into a void pointer, and then cast it back to the object pointer in a standard function.

Anything else will be some variation on this.

The way that member functions know which object they are operating on is by being passed a "object *this" as a hidden first argument to the function, so the call to a member function is different from a "normal" function - and there's no way around that.

--
Mats

And how do you suppose that should be done?

Adding a wrapper layer is really the only way to achieve that.

--
Mats

Boost.Bind can't do it. You can't get a real function pointer from Bind. Nor from Function.

The standard approach is this: callback mechanisms in C almost always allow you to pass a single pointer or pointer-sized integer along to the callback. You can put all data you need into this pointer: an object pointer, or even a full-blown Boost.Function object. You then specify a stub function as the callback, which does nothing but unpack the additional data and call the real callback.

If the API does not provide this additional parameter, you've got a really big problem. Frankly, I don't think it's possible to solve this problem in a portable way. (The non-portable way, of course, is to generate machine code that looks like a C-style function on the fly and pass a pointer to that.)

Yes. You could even use a thread-local storage area for the object pointer; that would at least solve the inevitable threading issues (at a certain performance cost). It would not, however, solve the problem of callbacks that are stored for later use instead of immediately used. (E.g. WndProc vs. qsort's comparison callback.)

Originally Posted by CornedBee

Yes. You could even use a thread-local storage area for the object pointer; that would at least solve the inevitable threading issues (at a certain performance cost). It would not, however, solve the problem of callbacks that are stored for later use instead of immediately used. (E.g. WndProc vs. qsort's comparison callback.)

And of course, the TLS solution only works when the same thread is the calling thread later on. [I guess that might be what you mean in "WndProc" cases - qsort certainly is only calling in the same thread].

--
Mats

Sorry to bring up an old point. Missed this one.

Originally Posted by pheres

I doesn't understand, why the language isn't improved to address the pointer conversion too, so that c-api can conveniently used in the world of OOP ...

First of all, no amount of redefining the language will fix the fact that there just isn't enough information in a single pointer to convey the information necessary to call a member function within a class without the calling code understanding that it IS a "_thiscall".

The Windows NT/2K/XP/Vista kernels are written in mainly in plain C (actually, I beleive the original Windows implementation was written in Pascal). Since the kernel isn't written in an object oriented language, it can't really "deal" with object oriented concepts in the callbacks etc. (there are OS's THAT ARE WRITTEN in for example C++, such as Chorus Streams and Symbian - and they often have "Objects" that take the place of a callback, so you pass in an object, and then whenever your "event" happens, a member function gets called).

--
Mats

The computer is fully able to. But the designer of the API didn't consider it. It's a human error.

(Actually, usually the designer of the API provided you with an additional void* pointer where you can pass whatever you want, so actually the designer did account for it. That makes it your error for not using this pointer.)