Es ist ein Implementierungsdetail, aber nein. Wenn eine Implementierung Zeiger auf nicht-virtuelle Funktionen in eine V-Tabelle einfügt, könnte sie diese Zeiger nicht zum Ausführen von Funktionsaufrufen verwenden, da dies oft dazu führen würde, dass nicht-virtuelle Funktionen inkorrekt aufgerufen werden.
Wenn eine nicht-virtuelle Funktion aufgerufen wird, muss die Implementierung den statischen Typ des Objekts, auf dem die Funktion aufgerufen wird, verwenden, um die richtige Aufruffunktion zu bestimmen. Eine in einem vtable gespeicherte Funktion, auf die ein vptr zugreift, hängt vom dynamischen Typ des Objekts ab und nicht von einem statischen Typ eines Verweises oder Zeigers, auf den zugegriffen wird .
Nein, tut es nicht.
Da Aufrufe nicht-virtueller Methoden während der Kompilierung aufgelöst werden können (da der Compiler die Adressen von nicht-virtuellen Funktionen kennt), erzeugt der Compiler Anweisungen, um sie "direkt" (d. h. statisch) aufzurufen.
Es gibt keinen Grund, den Mechanismus der vtable-Umleitung für Methoden zu durchlaufen, die beim Kompilieren bekannt sind.
Ob eine "vtable" von einer Implementierung verwendet wird, ist vom Standard nicht definiert. Die meisten Implementierungen verwenden eine Tabelle von Funktionszeigern, obwohl die Funktionen, auf die gezeigt wird, typischerweise nicht direkt diejenigen sind, die aufgerufen werden (stattdessen kann die auf die Funktion zeigende Funktion den Zeiger vor dem Aufruf der tatsächlichen Funktion anpassen).
Ob nicht-virtuelle Funktionen in dieser Tabelle angezeigt werden oder nicht, wird ebenfalls nicht vom Standard definiert. Schließlich erfordert der Standard nicht einmal die Existenz einer Vtable. Normalerweise befindet sich nicht-virtuelle Funktion nicht in einer virtuellen Funktionstabelle, da alle notwendigen Zeigereinstellungen und Aufrufe zur Compile- oder Link-Zeit aufgelöst werden können. Ich könnte mir eine Implementierung vorstellen, die alle Funktionen ähnlich behandelt und somit in allen Fällen einen Zeiger in der virtuellen Funktionstabelle verwendet. Ich würde nicht unbedingt sehr beliebt sein. Es könnte jedoch ein guter Weg sein, C ++ in einer Umgebung zu implementieren, in der es nahtlos mit einem flexibleren Objektsystem interagiert, z. B. Sprachen, in denen einzelne Funktionen zur Laufzeit ersetzt werden können (ich verstehe, dass so etwas möglich ist, z , in Python).