Warp wrote:
>   (With the next C++ standard things will get easier, as you will be able
> to write simply: "auto functionPointer = &A::foo;")
> 
>   You can call it like this:
> 
>     A a;
>     (a.*functionPointer)(5);

Oh, I see. No, I was talking about one object/pointer/variable etc that 
pointed to one instance's member function.

For example, in C#, if you have
   class A {
     public float abc;
     public int xyz(int pdq) { return (int) abc; }
     public static mno(int pdq) { return pdq*pdq; }
   }
   int (*point)(int);
   A alpha = new A();
   alpha.abc = 23.75;

then you can do
   point = &(alpha.xyz);
   int x = (*point)(23);
   point = &(A.mno);
   int y = (*point)(75);

/* I might have the syntax mildly wrong, and I'm probably using
    too many parens, but ... */

So the member pointer actually carries around the reference to the 
object, if it needs to. Or it can point to a static (non-member) 
function. I think Python does the same thing.

>   Also note that 'functionPointer' is in no way tied precisely to the
> foo() function. You can make it point to another member function with
> the same signature:
> 
>     functionPointer = &A::bar;
>     (a.*functionPointer)(5); // Now A::bar() is called

Yeah, but invoking it requires both the object and the pointer. *Now* I 
remember what is going on there. It definitely makes it easier to make 
data structures that deal with function pointers if you only care about 
the types of arguments and results, and not which class of object is 
implementing it. It does, obviously, add some overhead, of course. This 
way, you can have (say) an array of pointers to member functions, all of 
which are implemented by unrelated classes. I guess in C++ you could use 
MI to deal with something like that, while C# wouldn't support it the 
same way.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message