"The last feature": overridable methods in interfaces

Don nospam at nospam.com
Mon Feb 8 13:34:25 PST 2010


Steven Schveighoffer wrote:
> On Mon, 08 Feb 2010 15:13:33 -0500, Andrei Alexandrescu 
> <SeeWebsiteForEmail at erdani.org> wrote:
> 
>> Steven Schveighoffer wrote:
>>> On Mon, 08 Feb 2010 14:36:37 -0500, Andrei Alexandrescu 
>>> <SeeWebsiteForEmail at erdani.org> wrote:
>>>
>>>> Don wrote:
>>>>>  I don't understand this. How does belowTop() know how to call top()?
>>>>
>>>> It calls top() through the normal interface mechanism. Inside 
>>>> belowTop(), this has Stack!T type.
>>>  Actually, I think Don has a point here.  A virtual function (even on 
>>> an interface) is always called with the 'this' pointer, not the 
>>> interface pointer.
>>
>> That is done via an adjustment of the reference. In the case of an 
>> interface method, no adjustment is necessary. Inside the method, 
>> "this" has the static type of the interface and the dynamic type 
>> whichever class implements the interface.
> 
> 
> void foo(Stack!T st)
> {
>   auto x = st.belowTop();
> }
> 
> OK, so if st's virtual function for belowTop points to the default 
> implementation, there is no adjustment.  But what if the actual object 
> *did* override the default implementation?  Does it also receive the 
> interface pointer as 'this'?  Where does the adjustment happen?  What 
> happens if you have a reference to the actual concrete object type?  Do 
> you have to thunk to the correct interface to pass in the expected 
> interface pointer?  It can't be both ways.
> 
> -Steve

I have a strong suspicion that it's exactly the same as multiple 
inheritance.
I thought about this quite a bit a year ago, and initially I thought 
that having no data members made it OK. But it's deceptive.
Virtual member functions are still a problem. I think you can only have 
final functions.



More information about the Digitalmars-d mailing list