www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Pointers to non-static member functions!

reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
Currently, this compiles:

class A
{
    void func() {}
}

void main()
{
  auto p = &A.func;
}

In this case, typeof(p) is void function().
Calling one of these pointers, of course, can easily give you a segfault as 
it completely ignores the this pointer.
I didn't even realize you could do this until I saw 
http://d.puremagic.com/issues/show_bug.cgi?id=5986

I understand that it could be useful to have a way to get the address of a 
non-static member function, but I doubt returning a malformed function 
pointer is really useful.

Does anybody think changing &ClassType.nonStaticMember to return void* would 
be a bad idea?
Jun 08 2011
next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2011-06-08 04:00:53 -0400, "Daniel Murphy" <yebblies nospamgmail.com> said:


 Currently, this compiles:
 
 class A
 {
     void func() {}
 }
 
 void main()
 {
   auto p = &A.func;
 }
 
 In this case, typeof(p) is void function().
 Calling one of these pointers, of course, can easily give you a segfault as
 it completely ignores the this pointer.
 I didn't even realize you could do this until I saw
 http://d.puremagic.com/issues/show_bug.cgi?id=5986
 
 I understand that it could be useful to have a way to get the address of a
 non-static member function, but I doubt returning a malformed function
 pointer is really useful.
 
 Does anybody think changing &ClassType.nonStaticMember to return void* would
 be a bad idea?


I think it should work like my D/Objective-C language extension does it 
for selectors.
<http://michelf.com/projects/d-objc/syntax/#selector-literals>

&A.func should return a *member* function pointer which wants a 'this' 
parameter, and when you call it you should be required to add the 
'this' argument at the beginning of the argument list, like this:

	void main() {
		auto p = &A.func;
		p(new A);
	}

That'll probably require a syntax to specify a function type that wants 
a this pointer.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Jun 08 2011
parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Michel Fortin" <michel.fortin michelf.com> wrote in message 
news:isnj6i$2afd$1 digitalmars.com...

 I think it should work like my D/Objective-C language extension does it 
 for selectors.
 <http://michelf.com/projects/d-objc/syntax/#selector-literals>

 &A.func should return a *member* function pointer which wants a 'this' 
 parameter, and when you call it you should be required to add the 'this' 
 argument at the beginning of the argument list, like this:


This would be nice to have, but the compiler would need to use a different 
calling convention or generate multiple function beginnings, as the this 
parameter must be passed last.

This case is related to http://d.puremagic.com/issues/show_bug.cgi?id=2672
Jun 08 2011
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2011-06-08 09:24:43 -0400, "Daniel Murphy" <yebblies nospamgmail.com> said:


 This would be nice to have, but the compiler would need to use a different
 calling convention or generate multiple function beginnings, as the this
 parameter must be passed last.


True. What I mean is that a function type should know whether it needs 
a 'this' pointer or not, and implicit conversion between a function 
type that needs a this pointer and one that doesn't need one should be 
forbidden. And calling such a function directly would either not work, 
or would require a 'this' to be provided as the first argument (which 
is then put at the right place according to the ABI rules).

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Jun 08 2011
parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Michel Fortin" <michel.fortin michelf.com> wrote in message 
news:isoa8d$nif$1 digitalmars.com...

 True. What I mean is that a function type should know whether it needs a 
 'this' pointer or not, and implicit conversion between a function type 
 that needs a this pointer and one that doesn't need one should be 
 forbidden. And calling such a function directly would either not work, or 
 would require a 'this' to be provided as the first argument (which is then 
 put at the right place according to the ABI rules).


Ah I see.  This could probably be implemented quite easily, but I doubt it's 
worth the effort.  I think most cases can be done by casting and using a 
delegate.  I don't think pointers to members brought a lot to C++ (apart 
from complexity and syntax) and they seem mostly unnecessary with D's 
delegates.
Jun 08 2011
prev sibling next sibling parent reply Trass3r <un known.com> writes:
Am 08.06.2011, 10:00 Uhr, schrieb Daniel Murphy <yebblies nospamgmail.com>:


 Currently, this compiles:

 class A
 {
     void func() {}
 }

 void main()
 {
   auto p = &A.func;
 }

 In this case, typeof(p) is void function().


...

 Does anybody think changing &ClassType.nonStaticMember to return void*  
 would be a bad idea?


??
Shouldn't this just return a delegate?
Jun 08 2011
parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Trass3r" <un known.com> wrote in message news:op.vwq80v023ncmek enigma...

 ??
 Shouldn't this just return a delegate?


I don't think getting a delegate makes any sense without an instance.

I'm talking about this case:
class A
{
  void func();
}
void main()
{
    // returns a nonsense function pointer
    auto f = &A.func;

    // returns a working delegate
    auto a = new A();
    auto g = &a.func;
}
Jun 08 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 08 Jun 2011 09:27:21 -0400, Daniel Murphy  
<yebblies nospamgmail.com> wrote:


 "Trass3r" <un known.com> wrote in message  
 news:op.vwq80v023ncmek enigma...

 ??
 Shouldn't this just return a delegate?


 I don't think getting a delegate makes any sense without an instance.

 I'm talking about this case:
 class A
 {
   void func();
 }
 void main()
 {
     // returns a nonsense function pointer
     auto f = &A.func;

     // returns a working delegate
     auto a = new A();
     auto g = &a.func;
 }


The reason is to allow composition of delegates (not that I think this is  
a worthy reason):

class A
{
    void func();
    void func2();
}

void main()
{
    auto f = &A.func2;
    auto a = new A();
    auto g = &a.func; // delegate
    g.funcptr = f;
    g(); // calls a.func2()
}

I'd argue that a much more useful return type would be a delegate with the  
this pointer set to null, but then I don't know what funcptr would  
return.  I almost think you need a separate type for it, which seems like  
a lot of effort for something that's hardly used.

-Steve
Jun 08 2011
parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Steven Schveighoffer" <schveiguy yahoo.com> wrote in message 
news:op.vwrgycgjeav7ka localhost.localdomain...

 The reason is to allow composition of delegates (not that I think this is 
 a worthy reason):

 class A
 {
    void func();
    void func2();
 }

 void main()
 {
    auto f = &A.func2;
    auto a = new A();
    auto g = &a.func; // delegate
    g.funcptr = f;
    g(); // calls a.func2()
 }

 I'd argue that a much more useful return type would be a delegate with the 
 this pointer set to null, but then I don't know what funcptr would 
 return.  I almost think you need a separate type for it, which seems like 
 a lot of effort for something that's hardly used.

 -Steve


I can see this being useful, but I think it should be done by having 
delegate.funcptr be a void* and &ClassType.nonstaticmemberfunction return 
void*.
The type safety provided by the current way it works is an illusion, as the 
following compiles:

class A
{
  void func() { do something using member variables or the vtable etc }
}
class B
{
  void func() {}
}
void main()
{
  auto b = new B();
  auto dg = &b.func;
  dg.funcptr = &A.func;
  dg(); // Probably a segfault
}
Jun 08 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 08 Jun 2011 10:40:48 -0400, Daniel Murphy  
<yebblies nospamgmail.com> wrote:


 "Steven Schveighoffer" <schveiguy yahoo.com> wrote in message
 news:op.vwrgycgjeav7ka localhost.localdomain...

 The reason is to allow composition of delegates (not that I think this  
 is
 a worthy reason):

 class A
 {
    void func();
    void func2();
 }

 void main()
 {
    auto f = &A.func2;
    auto a = new A();
    auto g = &a.func; // delegate
    g.funcptr = f;
    g(); // calls a.func2()
 }

 I'd argue that a much more useful return type would be a delegate with  
 the
 this pointer set to null, but then I don't know what funcptr would
 return.  I almost think you need a separate type for it, which seems  
 like
 a lot of effort for something that's hardly used.

 -Steve


 I can see this being useful, but I think it should be done by having
 delegate.funcptr be a void* and &ClassType.nonstaticmemberfunction return
 void*.
 The type safety provided by the current way it works is an illusion, as  
 the
 following compiles:

 class A
 {
   void func() { do something using member variables or the vtable etc }
 }
 class B
 {
   void func() {}
 }
 void main()
 {
   auto b = new B();
   auto dg = &b.func;
   dg.funcptr = &A.func;
   dg(); // Probably a segfault
 }


Yes, but removing type safety does not prevent that from happening, plus  
it allows something like this:

class A
{
   void func();
   int func2();
}

void main()
{
    auto a = new A;
    auto dg = &a.func2();
    dg.funcptr = &A.func; // works if dg.funcptr and &A.func are void*, but  
doesn't work today
    int x = dg(); // runs and returns garbage
}

I almost would prefer that hacking delegates would be illegal.  Yes, you  
can get the function pointer and data pointer out of a delegate, but  
cannot set them.  I can't think of any good use cases for them.

I'm mixed on whether you should be able to get a member "function  
pointer".  It would be nice to simply make it a normal function pointer  
that you can call with the appropriate type.

BTW, if the calling convention is different, we may be able to allow it  
via creating a "this" function pointer:

assert(is(typeof(&A.func2) == int function(A this)));

Since this is a keyword, it can be interpreted as a different calling  
convention.

-Steve
Jun 08 2011
next sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Steven Schveighoffer" <schveiguy yahoo.com> wrote in message 
news:op.vwridsuteav7ka localhost.localdomain...

 Yes, but removing type safety does not prevent that from happening, plus 
 it allows something like this:

 class A
 {
   void func();
   int func2();
 }

 void main()
 {
    auto a = new A;
    auto dg = &a.func2();
    dg.funcptr = &A.func; // works if dg.funcptr and &A.func are void*, but 
 doesn't work today
    int x = dg(); // runs and returns garbage
 }


Fun fact: due to bug3797 if you change basically anything except the return 
type, it _will_ work today!


 I almost would prefer that hacking delegates would be illegal.  Yes, you 
 can get the function pointer and data pointer out of a delegate, but 
 cannot set them.  I can't think of any good use cases for them.


I think you're right on this.  I'll have a look and see how difficult making 
the delegate properties readonly is.  I have actually needed to manually 
construct a delegate when doing low level calling convention stuff, but you 
can always do this using unions or casts if you have to.


 I'm mixed on whether you should be able to get a member "function 
 pointer".  It would be nice to simply make it a normal function pointer 
 that you can call with the appropriate type.

 BTW, if the calling convention is different, we may be able to allow it 
 via creating a "this" function pointer:

 assert(is(typeof(&A.func2) == int function(A this)));

 Since this is a keyword, it can be interpreted as a different calling 
 convention.

 -Steve


I can see the theoretical appeal of having member function pointers or being 
able to call member functions as if they were globals, but I don't think the 
practical uses really justify introducing new syntax or types or changing 
the ABI.  I also don't think any option which does any of those things has a 
chance of getting incorporated into dmd.

If I can get some kind of consensus I'll try and patch dmd.
I think the following covers most of your points, given that you can still 
do the unsafe thing by casting:

Make delegate.funcptr read only and return void*
Make &ClassType.nonstaticmemberfunction return void*
Jun 08 2011
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 08 Jun 2011 11:19:12 -0400, Daniel Murphy  
<yebblies nospamgmail.com> wrote:


 I can see the theoretical appeal of having member function pointers or  
 being
 able to call member functions as if they were globals, but I don't think  
 the
 practical uses really justify introducing new syntax or types or changing
 the ABI.  I also don't think any option which does any of those things  
 has a
 chance of getting incorporated into dmd.


The issue becomes, what is the type of dg.funcptr?  And is it useable?  I  
don't know if returning void * is the right answer, one of the main things  
I think would be required is:

if(dg.funcptr is &A.func) {}

Which is really all you can do with a void *, so it does satisfy most  
requirements.  But I don't like that it can be passed into functions that  
for example, take a void *.  It just seems odd that you don't get any type  
information.

What I'd prefer is to have dg.funcptr return a new type like:

int function(void this)

which means, it cannot be called, because you don't know what type this  
is.  However, accessing the function pointer from the originating type  
would return:

int function(A this);

I don't think we need to change the ABI.  Calling the function with the  
given instance type would be the same as constructing the delegate and  
calling that delegate.

As far as "new" syntax, you may have a point.  I'll point out however that  
this is a seldom used "feature", and changing syntax would likely not  
affect very much code.


 If I can get some kind of consensus I'll try and patch dmd.
 I think the following covers most of your points, given that you can  
 still
 do the unsafe thing by casting:

 Make delegate.funcptr read only and return void*
 Make &ClassType.nonstaticmemberfunction return void*


Again, I think the read-only for funcptr is good, but void * seems too  
lax.  But it's an acceptable update, better than nothing.

-Steve
Jun 08 2011
prev sibling next sibling parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 08.06.2011 16:54, schrieb Steven Schveighoffer:

 
 I almost would prefer that hacking delegates would be illegal.  Yes, you
 can get the function pointer and data pointer out of a delegate, but
 cannot set them.  I can't think of any good use cases for them.
 
 I'm mixed on whether you should be able to get a member "function
 pointer".  It would be nice to simply make it a normal function pointer
 that you can call with the appropriate type.


That'd be nice. I think having a possibility to get a pointer to a
member function that you can use with any instance of the class the
method belongs to would be nice. Currently this should be possible by
using a delegate and changing its .ptr to the object you want to call
the method on (this won't work anymore if the delegates internal
pointers are read-only as suggested above).
This could be used for something like runtime-reflection (like Java's
Method class - which is horribly slow btw, compared to a direct call to
a method. For whatever reason.)
So you could use object.classinfo.getMembers(), look for the method you
want to use (with the name given at runtime!) and then use a function
pointer to that Method to efficiently call it on any object of the same
type. (So much for the theory, I don't see a way to find out the methods
signature to match it to the signature you want, especially for
overloaded methods - but maybe I just missed it.)

BTW: MemberInfo (and MemberInfo_field and MemberInfo_function) should be
documented in the object documentation.
And what does MemberInfo_function's typeInfo() return?
And is there a way to get a methods signature from MemberInfo_function?

(I hope this made sense and I didn't ignore a nicer way to do this - at
runtime - that is already implemented)

Cheers,
- Daniel
Jun 08 2011
prev sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2011-06-08 10:54:54 -0400, "Steven Schveighoffer" 
<schveiguy yahoo.com> said:


 On Wed, 08 Jun 2011 10:40:48 -0400, Daniel Murphy  
 <yebblies nospamgmail.com> wrote:
 

 "Steven Schveighoffer" <schveiguy yahoo.com> wrote in message
 news:op.vwrgycgjeav7ka localhost.localdomain...

 
 The reason is to allow composition of delegates (not that I think this  is
 a worthy reason):
 
 class A
 {
    void func();
    void func2();
 }
 
 void main()
 {
    auto f = &A.func2;
    auto a = new A();
    auto g = &a.func; // delegate
    g.funcptr = f;
    g(); // calls a.func2()
 }
 
 I'd argue that a much more useful return type would be a delegate with  the
 this pointer set to null, but then I don't know what funcptr would
 return.  I almost think you need a separate type for it, which seems  like
 a lot of effort for something that's hardly used.
 
 -Steve


 
 I can see this being useful, but I think it should be done by having
 delegate.funcptr be a void* and &ClassType.nonstaticmemberfunction return
 void*.
 The type safety provided by the current way it works is an illusion, as  the
 following compiles:
 
 class A
 {
   void func() { do something using member variables or the vtable etc }
 }
 class B
 {
   void func() {}
 }
 void main()
 {
   auto b = new B();
   auto dg = &b.func;
   dg.funcptr = &A.func;
   dg(); // Probably a segfault
 }


 
 Yes, but removing type safety does not prevent that from happening, 
 plus  it allows something like this:
 
 class A
 {
    void func();
    int func2();
 }
 
 void main()
 {
     auto a = new A;
     auto dg = &a.func2();
     dg.funcptr = &A.func; // works if dg.funcptr and &A.func are void*, 
 but  doesn't work today
     int x = dg(); // runs and returns garbage
 }
 
 I almost would prefer that hacking delegates would be illegal.  Yes, 
 you  can get the function pointer and data pointer out of a delegate, 
 but  cannot set them.  I can't think of any good use cases for them.


I was "hacking delegates" a lot in the D/Objective-C bridge (before I 
decided to bring things directly in the compiler). To make it short, I 
needed to do that to call the appropriate D function from Objective-C 
stub method implementation.



 BTW, if the calling convention is different, we may be able to allow it 
  via creating a "this" function pointer:
 
 assert(is(typeof(&A.func2) == int function(A this)));
 
 Since this is a keyword, it can be interpreted as a different calling  
 convention.


I was thinking about that too. Note that it forces int function(A this) 
to be implicitly castable to int function(void* this) when assigning to 
a delegate.


-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Jun 08 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 08 Jun 2011 13:07:50 -0400, Michel Fortin  
<michel.fortin michelf.com> wrote:


 On 2011-06-08 10:54:54 -0400, "Steven Schveighoffer"  
 <schveiguy yahoo.com> said:


 On Wed, 08 Jun 2011 10:40:48 -0400, Daniel Murphy   
 <yebblies nospamgmail.com> wrote:


 "Steven Schveighoffer" <schveiguy yahoo.com> wrote in message
 news:op.vwrgycgjeav7ka localhost.localdomain...

  The reason is to allow composition of delegates (not that I think  
 this  is
 a worthy reason):
  class A
 {
    void func();
    void func2();
 }
  void main()
 {
    auto f = &A.func2;
    auto a = new A();
    auto g = &a.func; // delegate
    g.funcptr = f;
    g(); // calls a.func2()
 }
  I'd argue that a much more useful return type would be a delegate  
 with  the
 this pointer set to null, but then I don't know what funcptr would
 return.  I almost think you need a separate type for it, which seems   
 like
 a lot of effort for something that's hardly used.
  -Steve


  I can see this being useful, but I think it should be done by having
 delegate.funcptr be a void* and &ClassType.nonstaticmemberfunction  
 return
 void*.
 The type safety provided by the current way it works is an illusion,  
 as  the
 following compiles:
  class A
 {
   void func() { do something using member variables or the vtable etc }
 }
 class B
 {
   void func() {}
 }
 void main()
 {
   auto b = new B();
   auto dg = &b.func;
   dg.funcptr = &A.func;
   dg(); // Probably a segfault
 }


  Yes, but removing type safety does not prevent that from happening,  
 plus  it allows something like this:
  class A
 {
    void func();
    int func2();
 }
  void main()
 {
     auto a = new A;
     auto dg = &a.func2();
     dg.funcptr = &A.func; // works if dg.funcptr and &A.func are void*,  
 but  doesn't work today
     int x = dg(); // runs and returns garbage
 }
  I almost would prefer that hacking delegates would be illegal.  Yes,  
 you  can get the function pointer and data pointer out of a delegate,  
 but  cannot set them.  I can't think of any good use cases for them.


 I was "hacking delegates" a lot in the D/Objective-C bridge (before I  
 decided to bring things directly in the compiler). To make it short, I  
 needed to do that to call the appropriate D function from Objective-C  
 stub method implementation.


The issue with hacking delegates I have is that almost certainly you know  
what the type of the function pointer is, which means you almost certainly  
have access to the member function for that type directly, it seems a very  
strange use case to be able to dynamically address the member functions of  
a class without knowing the type.  When I first wrote the above reason, I  
tried to think of a compelling real example, I couldn't.

Now, you are implementing a bridge to another language that supports a  
feature, which means you have to implement it.  But how often is that  
feature used in that other language?


 BTW, if the calling convention is different, we may be able to allow it  
  via creating a "this" function pointer:
  assert(is(typeof(&A.func2) == int function(A this)));
  Since this is a keyword, it can be interpreted as a different calling   
 convention.


 I was thinking about that too. Note that it forces int function(A this)  
 to be implicitly castable to int function(void* this) when assigning to  
 a delegate.


ATM, delegates and functions do not implicitly cast whatsoever.  In fact,  
I would not want the above cast to succeed, what should be implicitly cast  
is a contravariant function.  For example int function(Object this) should  
implicitly cast to int function(A this).

Now, a delegate does not record its 'this' type, so getting the function  
pointer for the delegate should yield an uncallable function pointer.  I  
proposed in another part of this thread the syntax:

int function(void this);

This at least gives you type information, but doesn't allow you to  
unsafely call it.  If you wish to explicitly cast it to a viable function,  
you can.

All this is dependent on the idea that a delegate cannot be constructed  
unless you have the original method (or a type-safe 'delegate-function'  
such as int function(A this)).  I really think that makes sense.

-Steve
Jun 08 2011
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2011-06-08 13:29:27 -0400, "Steven Schveighoffer" 
<schveiguy yahoo.com> said:


 On Wed, 08 Jun 2011 13:07:50 -0400, Michel Fortin  
 <michel.fortin michelf.com> wrote:
 

 On 2011-06-08 10:54:54 -0400, "Steven Schveighoffer"  
 <schveiguy yahoo.com> said:
 

 On Wed, 08 Jun 2011 10:40:48 -0400, Daniel Murphy   
 <yebblies nospamgmail.com> wrote:
 
  I almost would prefer that hacking delegates would be illegal.  Yes,  
 you  can get the function pointer and data pointer out of a delegate,  
 but  cannot set them.  I can't think of any good use cases for them.


 
 I was "hacking delegates" a lot in the D/Objective-C bridge (before I  
 decided to bring things directly in the compiler). To make it short, I  
 needed to do that to call the appropriate D function from Objective-C  
 stub method implementation.


 
 The issue with hacking delegates I have is that almost certainly you 
 know  what the type of the function pointer is, which means you almost 
 certainly  have access to the member function for that type directly, 
 it seems a very  strange use case to be able to dynamically address the 
 member functions of  a class without knowing the type.  When I first 
 wrote the above reason, I  tried to think of a compelling real example, 
 I couldn't.
 
 Now, you are implementing a bridge to another language that supports a  
 feature, which means you have to implement it.  But how often is that  
 feature used in that other language?


This is not at all a feature of Objective-C. This was a workaround. 
Tell me, if inside a template you have an alias to a member function, 
how can I call that member function? This won't work:

	void callMe(alias memberFunc)(Object o) {
		o.memberFunc(); // won't work, Object has no member called "memberFunc".
	}

What you can do is this:

	template Binding(alias memberFunc)(Object o) {
		void delegate() delegateToMember;
		delegateToMember.ptr = o;
		delegateToMember.funcptr = &memberFunc;
		delegateToMember();
	}

Although even there it won't work very well if your member is a virtual 
function. I needed to use an ever stranger workaround for that. Here's 
the actual code from the Objective-C bridge (it's a template which be 
mixed in the class):

	/**
	 * Template which can be mixed in a class to bind selector sel to instance
	 * method.
	 *
	 * This will create a receiver function which will forward the call to
	 * method, decapsulating arguments and encapsulating the return value as
	 * appropriate.
	 */
	template ObjcBindMethod(alias method, R, char[] sel, A...) {
	
		/**
		 * Resolve virtual function and return a delegate to it. This must be
		 * done from a non-static member function otherwise we can't get the
		 * address of the overriding function if there is one.
		 */
		private R delegate(A) resolveVirtualCall() {
			return &method;
		}
	
		/** Call forwarder for a virtual method of this class. */
		private static
		R forwardVirtualCall(objc.runtime.id self, objc.runtime.SEL _cmd, A args) {
			R delegate(A) delegate() resolve;
			resolve.ptr = objc.msg.send!(void*)(self, 
objc.method.selector!("d_object"));
			resolve.funcptr = &resolveVirtualCall;
			return resolve()(args);
		}
	
		mixin objc.bridge.ObjcMethodInfo!(forwardVirtualCall, R, sel, A);
	}

Here, the entry point from Objective-C is the forwardVirtualCall 
function, which does two things: it finds the object pointer, and then 
it resolves the virtual call, which can only be done in a non-static 
member function (resolveVirtualCall) because in the absence of an 
implicit this pointer it won't work.

Actually that's not really the entry point from Objective-C, there's a 
first entry point that performs argument conversion as necessary which 
then calls this one to call the right virtual function, but that's 
irrelevant to our case.

What would have really simplified things in all this is a C++-style 
pointer to member function type. But that's not part of D.



 BTW, if the calling convention is different, we may be able to allow it 
   via creating a "this" function pointer:
  assert(is(typeof(&A.func2) == int function(A this)));
  Since this is a keyword, it can be interpreted as a different calling  
  convention.


 
 I was thinking about that too. Note that it forces int function(A this) 
  to be implicitly castable to int function(void* this) when assigning 
 to  a delegate.


 
 ATM, delegates and functions do not implicitly cast whatsoever.  In 
 fact,  I would not want the above cast to succeed, what should be 
 implicitly cast  is a contravariant function.  For example int 
 function(Object this) should  implicitly cast to int function(A this).


You're right.



 Now, a delegate does not record its 'this' type, so getting the 
 function  pointer for the delegate should yield an uncallable function 
 pointer.  I  proposed in another part of this thread the syntax:
 
 int function(void this);
 
 This at least gives you type information, but doesn't allow you to  
 unsafely call it.  If you wish to explicitly cast it to a viable 
 function,  you can.


Makes sense.



 All this is dependent on the idea that a delegate cannot be constructed 
  unless you have the original method (or a type-safe 
 'delegate-function'  such as int function(A this)).  I really think 
 that makes sense.


I won't disagree with anything you say, because I do agree. I know my 
use case is a fringe one, and I don't need it anymore so I don't care 
much. And it'd only need one small thing for it to work without all 
that cumbersome hack:

	o.memberFunc() // where methodFunc is an alias to a member of o

which probably shouldn't be that difficult to implement in the 
compiler, what's needed is new syntax to distinguish it from a normal 
member call. Perhaps this?

	o.(memberFunc)()


-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Jun 08 2011
next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2011-06-08 14:13:46 -0400, Michel Fortin <michel.fortin michelf.com> said:


 I won't disagree with anything you say, because I do agree. I know my 
 use case is a fringe one, and I don't need it anymore so I don't care 
 much. And it'd only need one small thing for it to work without all 
 that cumbersome hack:
 
 	o.memberFunc() // where methodFunc is an alias to a member of o
 
 which probably shouldn't be that difficult to implement in the 
 compiler, what's needed is new syntax to distinguish it from a normal 
 member call. Perhaps this?
 
 	o.(memberFunc)()


Now that I think about it, perhaps UFCS would make all this unnecessary.

	void callMe(alias memberFunc)(Object o) {
		o.memberFunc(); // error, no member called "memberFunc" in o
		memberFunc(o); // works?
	}


-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Jun 08 2011
parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Michel Fortin" <michel.fortin michelf.com> wrote in message 
news:isog18$13vc$1 digitalmars.com...

 Now that I think about it, perhaps UFCS would make all this unnecessary.

 void callMe(alias memberFunc)(Object o) {
 o.memberFunc(); // error, no member called "memberFunc" in o
 memberFunc(o); // works?
 }


Somebody recently suggested making a parameter to enable a function to be 
called with ufcs.
void func(int a, int b, Object this) {}
A pointer to a function like this could be the same type as a member 
function pointer.
Jun 08 2011
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 08 Jun 2011 14:13:46 -0400, Michel Fortin  
<michel.fortin michelf.com> wrote:


 On 2011-06-08 13:29:27 -0400, "Steven Schveighoffer"  
 <schveiguy yahoo.com> said:


 On Wed, 08 Jun 2011 13:07:50 -0400, Michel Fortin   
 <michel.fortin michelf.com> wrote:


 On 2011-06-08 10:54:54 -0400, "Steven Schveighoffer"   
 <schveiguy yahoo.com> said:


 On Wed, 08 Jun 2011 10:40:48 -0400, Daniel Murphy    
 <yebblies nospamgmail.com> wrote:
   I almost would prefer that hacking delegates would be illegal.   
 Yes,  you  can get the function pointer and data pointer out of a  
 delegate,  but  cannot set them.  I can't think of any good use cases  
 for them.


  I was "hacking delegates" a lot in the D/Objective-C bridge (before  
 I  decided to bring things directly in the compiler). To make it  
 short, I  needed to do that to call the appropriate D function from  
 Objective-C  stub method implementation.


  The issue with hacking delegates I have is that almost certainly you  
 know  what the type of the function pointer is, which means you almost  
 certainly  have access to the member function for that type directly,  
 it seems a very  strange use case to be able to dynamically address the  
 member functions of  a class without knowing the type.  When I first  
 wrote the above reason, I  tried to think of a compelling real example,  
 I couldn't.
  Now, you are implementing a bridge to another language that supports  
 a  feature, which means you have to implement it.  But how often is  
 that  feature used in that other language?


 This is not at all a feature of Objective-C. This was a workaround. Tell  
 me, if inside a template you have an alias to a member function, how can  
 I call that member function? This won't work:

 	void callMe(alias memberFunc)(Object o) {
 		o.memberFunc(); // won't work, Object has no member called  
 "memberFunc".
 	}


In this case, the alias points at A.func or something like that, no?  So  
you have enough information to figure out that the member function is from  
A?  That is my point, you almost never *don't know* where the member  
function comes from.  And even if you don't, it's dangerous to simply  
assume this.

In my proposal, I'd guess that &memberFunc would give you a  
'delegate-function' pointer, which you could then cast o to the right type  
(assuming it is that type) and pass it into the function.

i.e.:

auto fptr = &memberFunc;
fptr(cast(thisType!(fptr))o); // thisType gets the type of the 'this'  
argument from the delegate-function pointer


 Although even there it won't work very well if your member is a virtual  
 function. I needed to use an ever stranger workaround for that. Here's  
 the actual code from the Objective-C bridge (it's a template which be  
 mixed in the class):


This is an entirely different thing, a delegate removes the virtual-ness  
of the call.  &A.func points to A's function, not to the virtual version  
(it can't possibly know that without an instance).  Having a way to say  
"call vtable entry for A.func" for a specific object would be nice, but is  
not a delegate.


 All this is dependent on the idea that a delegate cannot be constructed  
  unless you have the original method (or a type-safe  
 'delegate-function'  such as int function(A this)).  I really think  
 that makes sense.


 I won't disagree with anything you say, because I do agree. I know my  
 use case is a fringe one, and I don't need it anymore so I don't care  
 much. And it'd only need one small thing for it to work without all that  
 cumbersome hack:

 	o.memberFunc() // where methodFunc is an alias to a member of o


I'd much prefer memberFunc(o);  This is of course for a delegate-function  
pointer, not for an alias.  I'm not sure how an alias would work.

-Steve
Jun 08 2011
parent Michel Fortin <michel.fortin michelf.com> writes:
On 2011-06-08 15:21:47 -0400, "Steven Schveighoffer" 
<schveiguy yahoo.com> said:


 This is not at all a feature of Objective-C. This was a workaround. 
 Tell  me, if inside a template you have an alias to a member function, 
 how can  I call that member function? This won't work:
 
 	void callMe(alias memberFunc)(Object o) {
 		o.memberFunc(); // won't work, Object has no member called  "memberFunc".
 	}


 
 In this case, the alias points at A.func or something like that, no?


Exactly.


 So  you have enough information to figure out that the member function 
 is from  A?


Yes. (Although I'm not sure you can extract this info from the alias, 
the compiler has it, and I have it through other means, namely 
typeof(this)).


 That is my point, you almost never *don't know* where the member  
 function comes from.  And even if you don't, it's dangerous to simply  
 assume this.


The member function here is an alias, the compiler knows where this 
function comes from and can check whether the 'this' pointer is of the 
right type. It just won't let us call it because there's no syntax. 
That's the core of the problem.

I worked around that by adding a non-virtual member function that just 
returns a delegate to the virtual one.

Constructing the delegate manually is a workaround to call that 
non-virtual member. I can't call even a non-virtual member function 
without it because I mixin the same template many times within the same 
class, which creates ambiguous overloads for "resolveVirtualCall". 
Taking the address directly and assigning it to a delegate works 
because I'm not getting the symbol through the object but through the 
current scope which gives precedence to a function in the template 
scope. To make that clear, this works:

	private static
	R forwardVirtualCall(objc.runtime.id self, objc.runtime.SEL _cmd, A args) {
		R delegate(A) delegate() resolve;
		resolve.ptr = objc.msg.send!(void*)(self, objc.method.selector!("d_object"));
		resolve.funcptr = &resolveVirtualCall;
		return resolve()(args);
	}

while this doesn't when mixing in the templates multiple times within a class:

	private static
	R forwardVirtualCall(objc.runtime.id self, objc.runtime.SEL _cmd, A args) {
		auto o = cast(typeof(this))objc.msg.send!(void*)(self, 
objc.method.selector!("d_object"));
		return o.resolveVirtualCall()(args);
	}

It gives this error:

	/objc/bridge.d(253): Error: 
cocoa.foundation.date.NSDate.ObjcBindMethod!(opAdd,NSDate,"addTimeInterval:",double
.resolveVirtualCall 
at /cocoa/foundation/date.d(245) conflicts with 
cocoa.foundation.date.NSDate.ObjcBindMethod!(isEqualToDate,bool,"isEqualToDate:",NSDate
.resolveVirtualCall 
at /cocoa/foundation/date.d(245)

I'm sorry if this wasn't clear the first time, I think it wasn't for me 
either. It's been a long time since I written or even used that code.

To, to summarize: Calling a virtual function relied on defining and 
calling a non-virtual member. A non-virtual member which was ambiguous 
and could be called only through a manually-crafted delegate. Hence my 
need for a manually crafted delegate.



 In my proposal, I'd guess that &memberFunc would give you a  
 'delegate-function' pointer, which you could then cast o to the right 
 type  (assuming it is that type) and pass it into the function.
 
 i.e.:
 
 auto fptr = &memberFunc;
 fptr(cast(thisType!(fptr))o); // thisType gets the type of the 'this'  
 argument from the delegate-function pointer


That would probably work as it's just sugar for creating a delegate 
manually, with some added type safeties.



 Although even there it won't work very well if your member is a virtual 
  function. I needed to use an ever stranger workaround for that. Here's 
  the actual code from the Objective-C bridge (it's a template which be  
 mixed in the class):


 
 This is an entirely different thing, a delegate removes the 
 virtual-ness  of the call.  &A.func points to A's function, not to the 
 virtual version  (it can't possibly know that without an instance).  
 Having a way to say  "call vtable entry for A.func" for a specific 
 object would be nice, but is  not a delegate.


It'd be nice to have that, even if just as a library solution. Do we 
have a __traits to get the vtable offset of a function?



 All this is dependent on the idea that a delegate cannot be constructed 
   unless you have the original method (or a type-safe  
 'delegate-function'  such as int function(A this)).  I really think  
 that makes sense.


 
 I won't disagree with anything you say, because I do agree. I know my  
 use case is a fringe one, and I don't need it anymore so I don't care  
 much. And it'd only need one small thing for it to work without all 
 that  cumbersome hack:
 
 	o.memberFunc() // where methodFunc is an alias to a member of o


 
 I'd much prefer memberFunc(o);  This is of course for a 
 delegate-function  pointer, not for an alias.  I'm not sure how an 
 alias would work.


Agree. Also, an alias could work using the same syntax too if we had UFCS. :-)


-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Jun 08 2011
prev sibling next sibling parent reply Jason House <jason.james.house gmail.com> writes:
Daniel Murphy Wrote:


 Currently, this compiles:
 
 class A
 {
     void func() {}
 }
 
 void main()
 {
   auto p = &A.func;
 }
 
 In this case, typeof(p) is void function().


Shouldn't it be void function(A)? As long as the ABI supports it, that would
make the most sense to me... As I understand it, the this pointer is just a
hidden parameter.
Jun 08 2011
parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Jason House" <jason.james.house gmail.com> wrote in message 
news:isntm4$2ull$1 digitalmars.com...

 Shouldn't it be void function(A)? As long as the ABI supports it, that 
 would make the most sense to me... As I understand it, the this pointer is 
 just a hidden parameter.


Unfortunately the ABI doesn't support it.  'this' must always be the last 
parameter, so that kind of conversion would only work for a subset of 
functions.

eg.
class A
{
    int funcA(int);
}
is equivalent to:
int function(int, A)

and
struct S { int a, b, c; }
class A
{
    S funcA(int);
}
is equivalent to:
void function(int, S*, A)
Jun 08 2011
prev sibling next sibling parent reply David Nadlinger <see klickverbot.at> writes:
Oh wow, my previous comment was total nonsense, I confused .func with 
the delegate .funcptr property…

The bugs probably comes from the delegate .funcptr property being a 
function pointer of the same signature as the delegate type itself, 
which doesn't make too much sense: 
http://d.puremagic.com/issues/show_bug.cgi?id=2672. Presumably because 
of this, &A.func also has the same type so things match up.

However, as not every delegate can be called as a function because of 
ABI reasons (think about the hidden struct return pointer), changing the 
type of delegate.funcptr to void* as well might be the better solution.

David


On 6/8/11 10:00 AM, Daniel Murphy wrote:

 Currently, this compiles:

 class A
 {
      void func() {}
 }

 void main()
 {
    auto p =&A.func;
 }

 In this case, typeof(p) is void function().
 Calling one of these pointers, of course, can easily give you a segfault as
 it completely ignores the this pointer.
 I didn't even realize you could do this until I saw
 http://d.puremagic.com/issues/show_bug.cgi?id=5986

 I understand that it could be useful to have a way to get the address of a
 non-static member function, but I doubt returning a malformed function
 pointer is really useful.

 Does anybody think changing&ClassType.nonStaticMember to return void* would
 be a bad idea?
Jun 08 2011
parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"David Nadlinger" <see klickverbot.at> wrote in message 
news:iso2fc$6a2$1 digitalmars.com...

 Oh wow, my previous comment was total nonsense, I confused .func with the 
 delegate .funcptr property.

 The bugs probably comes from the delegate .funcptr property being a 
 function pointer of the same signature as the delegate type itself, which 
 doesn't make too much sense: 
 http://d.puremagic.com/issues/show_bug.cgi?id=2672. Presumably because of 
 this, &A.func also has the same type so things match up.

 However, as not every delegate can be called as a function because of ABI 
 reasons (think about the hidden struct return pointer), changing the type 
 of delegate.funcptr to void* as well might be the better solution.

 David


I think the botched type comes from the compiler's implementation - function 
types have no idea wheather they have a this parameter or not!
I'm currently thinking changing &ClassType.nonstaticmemberfunction and 
delegate.funcptr to return void*, and making delegate.funcptr read-only 
should smooth off this nasty corner quite nicely.
Jun 08 2011
prev sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
Turned out it was even easier to do than I expected:

https://github.com/yebblies/dmd/commit/ed7a499d689940fd21d23bb658e97b1024a7d6be

I'm not sure if delegate.funcptr should return a void* lvalue or a 
const(void)* rvalue though.  The latter would allow you to cast away const 
and mess with it.
Jun 08 2011
parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Daniel Murphy" <yebblies nospamgmail.com> wrote in message 
news:isofvu$13tv$1 digitalmars.com...

 Turned out it was even easier to do than I expected:

 https://github.com/yebblies/dmd/commit/ed7a499d689940fd21d23bb658e97b1024a7d6be

 I'm not sure if delegate.funcptr should return a void* lvalue or a 
 const(void)* rvalue though.  The latter would allow you to cast away const 
 and mess with it.


swap lvalue and rvalue!
Jun 08 2011