Pointers to non-static member functions!
Michel Fortin
michel.fortin at michelf.com
Wed Jun 8 10:07:50 PDT 2011
On 2011-06-08 10:54:54 -0400, "Steven Schveighoffer"
<schveiguy at yahoo.com> said:
> On Wed, 08 Jun 2011 10:40:48 -0400, Daniel Murphy
> <yebblies at nospamgmail.com> wrote:
>
>> "Steven Schveighoffer" <schveiguy at yahoo.com> wrote in message
>> news:op.vwrgycgjeav7ka at 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 at michelf.com
http://michelf.com/
More information about the Digitalmars-d
mailing list