"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