M
John1 schrieb:
OK, da ich jemand bin der sich meist umfangreich über das informiert was er benutzt, hatte ich auch sehr viel über "virtual" und die Virtuelle-Methoden-Tabelle gelesen. und aus dem was ich gelesen habe, hatte ich geschlussfolgert, dass es inperformanter sein muss, als wenn man sich lieber selbst mehr "Schreibarbeit" macht.
Es ist praktisch vernachlässigbar. Ein virtual Aufruf an sich ist nichts was irgendwie "Zeit kosten" würde, da gehts um paar Taktzyklen. Ein virtual Aufruf ist im Gegensatz zu einem normalen Funktionsaufruf ein indirekter Sprung. Das ist etwas schwieriger für die Branch Prediction vom Prozessor. Aber wenn du die Funktion paar mal aufrufst, dann sind es wie gesagt vielleicht paar Taktzyklen Unterschied. Und wenn du die Funktion paar Milliarden mal aufrufst, dann kriegt es die Branch Prediction wahrscheinlich auch auf die Reihe. Und normalerweise fällt sowas im Vergleich zu der Funktion, die du aufrufen willst, in keinster Weise ins Gewicht.
SetColor, SetPosition usw. hättest du doch gar nicht virtuell machen brauchen. Um das alles kann sich die Basisklasse kümmern, das muss nicht virtuell sein. Was virtuell sein müsste wäre sowas wie eine "create" Methode, die sich dann drum kümmert, das Objekt wirklich zu erstellen. Und jetzt stell dir vor, die wäre wegen virtual 20 Taktzyklen langsamer. Ruft dann aber CreateWindowEx auf usw., verbrät also insgesamt wahrscheinlich zig Millionen Taktzyklen. Das reicht nicht als Argument, um deswegen eine sehr ungewöhnliche und unflexible Softwarearchitektur aufzuziehen
