Don wrote:
Steven Schveighoffer wrote:
On Mon, 08 Feb 2010 15:13:33 -0500, Andrei Alexandrescu
<[email protected]> wrote:
Steven Schveighoffer wrote:
On Mon, 08 Feb 2010 14:36:37 -0500, Andrei Alexandrescu
<[email protected]> 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.
I think it's only data. The problem is that you end up storing multiple
copies of the same interface object inside the final object. As long as
the per-interface state is compiler-maintained and immutable, you should
be in good shape.
Andrei
