delegate cannot handle polymorphism?

[Timon Gehr]

Nub Public wrote:
> On 6/27/2011 7:08 PM, Michel Fortin wrote:
>> On 2011-06-27 03:30:09 -0400, Nub Public <nubpublic at gmail.com> said:
>>
>>> class BOn 6/27/2011 7:08 PM, Michel Fortin wrote:
>> On 2011-06-27 03:30:09 -0400, Nub Public <nubpublic at gmail.com> said:
>>
>>> class B
>>> {
>>> void fun() { writeln("B"); }
>>> }
>>>
>>> class D : B
>>> {
>>> override void fun() { writeln("D"); }
>>> }
>>>
>>> void delegate() dg = &b.fun;
>>> dg.ptr = cast(void*)d;
>>> dg();
>>>
>>>
>>> Compiler: DMD 2.053
>>> It prints "B" instead of "D".
>>> The equivalent code in C++ prints "D" nicely.
>>
>> C++ doesn't have delegates, and D doesn't have member function pointers.
>> Resolving virtual functions is done while you take its address in D,
>> while in C++ the member function pointer type contains holds the vtable
>> offset (or several in the case of multiple inheritance) which gets
>> resolved only when you call the function.
>>
>> If you want the C++ behaviour, try using a delegate literal as a
>> trampoline that gets the object as a parameter to then call your function:
>>
>> void delegate(B b) dg = (B b) { b.fun(); };
>>
>> dg(d);
>>
>
>
> Thank you. That was very helpful.
>
> What's the rational for this behavior though? Resolving the address of a
> virtual function at compile time seems a little counter-intuitive to me.
> I guess this way is slightly more efficient.

A delegate literal consists of a function pointer and a context pointer. There is
no polymorphism in that. A member function is a normal function you can take the
address of.
In general, you shouldn't update one of (ptr,funcptr) without updating the other
unless you have good reasons to do so and know exactly what you are doing.
Not having member pointers is AFAIK a direct consequence of the fact that nobody
uses them in C++ and almost nobody even knows that they exist.
Furthermore, their implementation is too involved, given their limited usefulness.

Cheers,
-Timon