In the dreaded diamond there is a single base, from which the two intermediate objects derive and then the fourth type closes the diamond with multiple inheritance from both types in the intermediate levels.
Your question seems to be how many f
functions are declared in the previous example? and the answer is one.
Lets start with the simpler example of a linear hierarchy of just base and derived:
struct base {
virtual void f() {}
};
struct derived : base {
virtual void f() {}
};
In this example there is a single f
declared for which there are two overrides, base::f
and derived::f
. In an object of type derived
, the final overrider is derived::f
. It is important to note that both f
functions represent a single function that has multiple implementations.
Now, going back to the original example, on the line on the right, Base::f
and Right::f
are in the same way the same function that is overridden. So for an object of type Right
, the final overrider is Right::f
. Now for a final object of type Left
, the final overrider is Base::f
as Left
does not override the function.
When the diamond is closed, and because inheritance is virtual
there is a single Base
object, that declares a single f
function. In the second level of inheritance, Right
overrides that function with its own implementation and that is the final overrider for the most derived type Bottom
.
You might want to look at this outside of the standard and take a look at how this is actually implemented by compilers. The compiler, when creating the Base
object it adds a hidden pointer vptr
to the virtual table. The virtual table holds pointers to thunks (for simplicity just assume that the table held pointers to the function's final overriders, [1]). In this case, the Base
object will contain no member data and just a pointer to a table that holds a pointer to the function Base::f
.
When Left
extends Base
, a new vtable is created for Left
and the pointer in that vtable is set to the final overrider of f
at this level, which is incidentally Base::f
so the pointers in both vtables (ignoring the trampolin) jump to the same actual implementation. When an object of type Left
is being constructed, the Base
subobject is initialized first, and then prior to initialization of the members of Left
(if there were) the Base::vptr
pointer is updated to refer to Left::vtable
(i.e. the pointer stored in Base
refers to the table defined for Left
).
On the other side of the diamond, the vtable that is created for Right
contains a single thunk that ends up calling Right::f
. If an object of type Right
was to be created the same initialization process would happen and the Base::vptr
would point to Derived::f
.
Now we get to the final object Bottom
. Again, a vtable is generated for the type Bottom
and that vtable, as is the case in all others, contains a single entry that represents f
. The compiler analyzes the hierarchy of inheritance and determines that Right::f
overrides Base::f
, and there is no equivalent override on the left branch, so in Bottom
's vtable the pointer representing f
refers to Right::f
. Again, during construction of the Bottom
object, the Base::vptr
is updated to refer to Bottom
's vtable.
As you see, all four vtables have a single entry for f
, there is a single f
in the program, even if the value stored in each vtable is different (the final overriders differ).
[1] The thunk is a small piece of code that adapts the this
pointer if needed (multiple inheritance usually implies it is needed) and then forwards the call to the actual override. In the event of single inheritance, the this
pointer does not need to be updated and the thunk disappears, with the entry in the vtable pointing directly to the actual function.