method returning child, doesn't overrides declared method returning parent

[Timon Gehr]

On 08/30/2011 07:29 PM, Steven Schveighoffer wrote:
> On Tue, 30 Aug 2011 13:21:09 -0400, Timon Gehr <timon.gehr at gmx.ch> wrote:
>
>> On 08/30/2011 07:06 PM, Steven Schveighoffer wrote:
>>> On Tue, 30 Aug 2011 12:55:30 -0400, Timon Gehr <timon.gehr at gmx.ch>
>>> wrote:
>>>
>>>> On 08/30/2011 06:23 PM, Steven Schveighoffer wrote:
>>>>> On Tue, 30 Aug 2011 12:18:32 -0400, Timon Gehr <timon.gehr at gmx.ch>
>>>>> wrote:
>>>>>
>>>>>> On 08/30/2011 06:00 PM, Steven Schveighoffer wrote:
>>>>>>> On Tue, 30 Aug 2011 11:58:43 -0400, Timon Gehr <timon.gehr at gmx.ch>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On 08/30/2011 05:49 PM, Christophe wrote:
>>>>>>>>> The fact that the code compile only if all interface methods are
>>>>>>>>> implemented does not imply that the programmer knows which
>>>>>>>>> method he
>>>>>>>>> implemented hooks and which does not.
>>>>>>>>
>>>>>>>> interface I{
>>>>>>>> void method();
>>>>>>>> }
>>>>>>>>
>>>>>>>> class C: I{
>>>>>>>> void method() {} // not a hook.
>>>>>>>> }
>>>>>>>
>>>>>>> Why not? All a "hook" is is adding an entry into a base class'
>>>>>>> vtable.
>>>>>>> This is no different, it's just the base "class" is an interface.
>>>>>>>
>>>>>>> -Steve
>>>>>>
>>>>>> As far as I can tell, a hook is overwriting an existing entry.
>>>>>
>>>>> Nothing is "overwritten", what's written into the table is decided at
>>>>> compile-time.
>>>>>
>>>>> -Steve
>>>>
>>>> It is conceptually "overwritten" at compile time: Copy vtable from
>>>> parent and replace the overriden entries.
>>>
>>> And that's no different from implementing an interface, or an abstract
>>> class that does not implement an interface completely -- copy the vtable
>>> and overwrite the entries.
>>
>> interfaces don't possess an own vtable. It is created from scratch for
>> each class implementing the interface.
>
> The vtable for the interface is identical in layout for each class
> implementing it.

What I was saying is not that there is no specific layout, just that an 
interface by itself does not need to be represented in the object file. 
All interface vtbls are part of the classinfo of the implementing classes.

in

interface I{
     void method();
}
class C: I{
     void method(){}
}

No overriding of an existing implementation is taking place, the 
interface inheritance creates a new interface vtable.

> So if foo() lives at index 0 in the function table for
> class C, it lives at index 0 for class D as well. Otherwise,
> polymorphism wouldn't work, and neither would delegates to interfaces.
>
> When you call an interface function, the thunk subtracting the offset to
> get to the class pointer is done by a pre-function code piece, then the
> real function is jumped to.
>
> So yes, each interface has its own vtable layout, similar to how an
> abstract class with no implementations would have its own vtable, even
> though it's not instantiable.
>

Why would an abstract class without implementations need a vtable in the 
object file?