Ein Standard ist compilerspezifischen Lösungen vorzuziehen, findest du nicht? Und wie schon gesagt: Wenn alle es sowieso tun, dann ist es ein Defacto-Standard.
Eben gerade deshalb darf das nicht in den Standard. Erwähnst du im Standard irgendwas von VMT usw erwähnst zwingst du alle VMT zu verwenden, hat jemand eine bessere Idee darf er diese nicht einsetzen, weil er sonst gegen den Standard verstösst. Reduzierst du 'direct' darauf, dass eine Methode nicht weiter überschrieben werden kann musst du das nicht mit einem neuen Keyword machen, dieses Keyword gibts es schon und es nennt sich 'final'.
Ja. Doch der Compiler muss die Basisklassen kennen, wenn er eine Kindklasse bekommt. Umgekehrt gilt das nicht. "direct" (ich nenne es jetzt mal so, von mir aus heisst es auch anders) würde ja eben garantieren, dass von einer (Kind-)klasse keine neuen Morphien entstehen, also nicht nochmals vererbt wird. Dann kann der Compiler alle Funktionen auflösen und braucht keine VMT.
Ob von einer Kindklasse geerbt wird oder nicht ist doch nicht weiter relevant. Fakt ist, dass jemand der die Basisklasse kennt die Kindklasse nicht kennen muss. Das direct Keyword würde dann nur Sinn machen, wenn es auf Base angewandt wird, weil dann der Compiler weiss, dass er nach einem Symbol Base::func suchen muss und einen Aufruf darauf verwenden kann und nicht irgendwelche virtuellen Funktionen aufrufen muss. Das würde aber wiederum bedeuten, dass Base gar keine virtuellen Methoden haben muss, da es ja sowieso nicht vererbt werden kann.
Function Casts können template-isiert werden, wenn das Keyword gesetzt wurde. Ist es einfach? Nein. Aber sind wir uns nicht einig, dass es im jetzigen System zwar generell ideal gelöst ist, im Bezug auf Performance aber nicht?
foo in meinem Beispiel kann nur dann einmal für VMTD und einmal für NoVMTD templateisiert werde, wenn zum Zeitpunkt des Aufrufs der ursprüngliche Code von foo noch bekannt ist. Das ist nur dann der Fall, wenn foo im gleichen Translationunit verarbeitet wird wie der Aufruf an foo. Wenn dem so ist brauchst du das Keyword auch nicht, weil der Compiler/Optimierer dann selber so schlau sein kann das einzubauen, wenn ihm danach ist.
Der Typ ist ja noch gegeben. Das Problem würde erst bei (void*)-Parametern (oder falsch gecasteten) entstehen. Ansonsten wie oben angesprochen: Statt den Pointer direkt zu übernehmen kann der Typ und damit die Funktionsaufrufe in der Funktion angepasst werden.
Gleiches Problem wie oben. Innerhalb der Methode foo ist o.B.d.A nichts mehr über den Typen bekannt. Die entsprechende Ersetzung des Codes abhängig von VMT oder Nicht-VMT müsste also beim Aufruf passieren, dies setzt aber voraus, dass die Funktion in einer Form vorliegt, in der eine solche Übersetzung überhaupt noch möglich ist. Damit sie das ist müsste sie, wie du erwähntest, sozusagen als template markiert werden, damit sie nicht in Objektcode sondern in eine ersetzbare Schablone umgewandelt wird. Dazu brauchen wir aber auch kein neues Keyword, dazu kannst du schlicht template verwenden.
C++:
template<typename T>
void foo(T* ptr) {
ptr->func();
}
Der Compiler/Optimierer kann nun bei jedem Aufruf entscheiden welche Variante er nehmen möchte und wie er das umsetzen will, da es sich ja nur um ein template handelt.
Ja. Ist es nicht das, was ich eigentlich will? Eine Klasse, die zwar wie jede andere Eigenschaften und Funktionen erben kann, was zur Laufzeit aber nicht mehr von einer komplett statischen Klasse zu unterscheiden ist?
Nein, dann müsstest du deinem keyword noch weitere Eingeschaften hinzufügen. So müsste zum Beispiel Derived von Base immer private erben. Also Derived ist dann kein Base mehr, kann auch nicht mehr in ein Base umgewandelt werden und hat überhaupt keine Relation mehr zu Base, ausser dass es halt die Methoden und Felder einfach übernimmt. Ob das schon ausreicht kann ich dir nicht sagen, du musst jeglichen Fall durchdenken, den es gibt wie man Derived polymorph verwenden könnte und das unterbinden. Das kann man auch nicht dem Compiler überlassen, das muss so im Standard stehen.
Das soll das Keyword garantieren. Es ist eben nicht mehr riskant, wenn sicher ist, dass nicht weiter (nach aussen) vererbt wird.
Wie erwähnt ist das weitervererben nicht der riskante Punkt davon.
Ist es ja nicht. Es ist ein Keyword der Gattung "Ich verspreche, dass du keine VMT brauchst.". Wenn man Versprechen gibt, muss man sie halten - oder mit den Konsequenzen leben. Mir fällt gerade kein richtiges Keyword ein, bei dem das ähnlich ist (new ist ja eher Funktion als Keyword...), aber bei new ist es ähnlich: Wenn ich kein Testing auf Exceptions oder nullptr mache, dann fliegt mir das Ding um die Ohren. Soll ich deswegen auch sagen "new ist schlecht, macht alles nur noch auf dem Stack"?
Du kannst bei der Klasse nicht entscheiden ob eine VMT nötig ist oder nicht, das entscheidet die Verwendung. Den Zusammenhang zu new versteh ich nicht. Es ist im Standard klar definiert, was passiert, wenn eine Exception nicht abfangen wird und ein nullptr ist auch nichts undefiniertes.
Ja. Denn der Mensch kann Haltingprobleme lösen. Der Mensch kann wissen, ob er eine Klasse nach aussen geben will oder nicht. Ich weiss, es gibt die "Don't help the Compiler"-Einstellung. Aber gerade hier, wo man potentiell 1/3 der Laufzeit sparen kann, wäre sowas praktisch.
In der realen Welt hat eine VMT keinen nennenswerten Einfluss auf die Laufzeit. Wo Mikrooptimierungen in diesem Ausmasse nötig sind sollte man gleich auf C umsteigen. Dort herrscht generell ja auch die Akzeptanz, dass dich jede Instruktion aus nicht-reproduzierbaren und nicht-debuggbaren Gründen ins Nirvana kicken kann.
Wenn du mir nicht glaubst kannst du dir gern andere Meinungen einholen...
. Wenn es in der Basisklasse virtuelle Funktionen gibt ist eine VMT immer nötig, sonst kann jemand, der einen Pointer auf die Basisklasse verwendet ja gar nicht wissen, was passiert. Zudem verstehe ich jetzt auch nicht warum in deiner zweiten Klasse keine VMT nötig sein soll. 
