[ryao]

The vtable pointer corresponds to the actual type in languages that use vtables to implement inheritance, so you do know the type.

Read my previous comment for the bug that would happen if what us being used in Linux were actually used for dynamic dispatch when implementing inheritance, and it should be clear this is something similar, but different.

[1718627440]

No the type of an object isn't known until runtime, so the compiler can't know it. Yes you know the type of the vtable, which means you know the supertype. This is true in all languages that don't use duck-typing. No you don't know the assigned values of entries in the vtable, which means you don't know the type of the object.

> Read my previous comment for the bug

No this is not a bug. The entire point of inheritance or dynamic dispatch IS that you call a function from "a different class" aka the subclass the object is an instance of. This is not a bug, this is the entire point of implementing it with vtables.

[ryao]

I never said that the type was known before runtime in OO. Your not a bug comment sounds awfully like an all bugs are features. Implementing static member functions this way would cause undefined behavior, which is a bug.

[1718627440]

> Implementing static member functions this way would cause undefined behavior, which is a bug.

Yes. My point is, that it can't be a static member function, because it's overridden by subclasses.

[ryao]

It cannot be overridden by subclasses without risking undefined behavior because there is no this pointer for it to use.

[1718627440]

Yes it can. It simply means the subclass implementation has no access to a this pointer. When would undefined behaviour occur here? When a function tries to use a parameter that does not exist in the function signature, that's a compile time error not UB.

Maybe you think that, because a this pointer is needed for dynamic dispatch? A this pointer exists there, it is just not passed to the implementation.