K
null schrieb:
Was kosten virtuelle Funktionen wirklich(vtable und co.)?
nur einen eindirekten jsr/call und die übergabe des this-pointers als zusätzlichen versteckten funktionsparameter.
auf den meisten 32-bit-cpus kosten indirekte calls nur 2-3 taktzyklen mehr. der this-pointer wird normalerweise in einem prozessorregister übergeben. wenn man bedenkt, daß ein funktionsaufruf auch noch die parameterübergabe, das retten und wiederherstellen von prozessorregistern, das anlegen von speicher für die lokalen variablen und das aufräumen des stacks kostet, dann fällt das kaum ins gewicht.der zugriff auf objektvariablen indirekt über den this-pointer geht auf den meisten prozessoren sogar schneller als der zugriff auf eine globale variable.
HumeSikkins schrieb:
Ein virtueller Methodenaufruf ist zwar teurer als ein nicht-virtueller. Aber meistens entfällt beim virtuellen Aufruf dafür auch eine if- bzw. switch-Anweisung.
sehe ich genauso. und wenn man daten nicht über objektvariablen an eine element-funktion übergibt, dann muß man sich mit der übergabe eines zeigers auf eine datenstruktur behelfen und das ist doppelt langsamer: erstens wird die dann nicht in einem prozessorregister übergeben und zweitens ist der zugriff auf die felder auch wesentlich teurer.
wenn man es nicht in c++ macht, dann muß man es mit mehr code-aufwand in c schreiben. und das ist meist auch nicht effizienter.
was exceptions angeht, die sollten eigentlich nicht mehr rechenzeit in anspruch nehmen als die übliche fehlerbehandlung mit if's. der exception-mechanismus fuktioniert wie ein longjump und benötigt nur rechenzeit, wenn eine exception ausgelöst wird. es wird etwas mehr stack-speicher benötigt, weil catch, ähnlich wie setjump, die cpu-register auf den stack rettet. aber eigentlich machen exceptions das programm kürzer, weil man sich die if-orgien der herkömmlichen fehlerbehandlung spart. ob man exceptions verwendet hängt nicht von den effizenzanforderungen ab sondern von der architektur des programms. bei kleinen und einfachen programmen hieße exceptions zu verwenden halt mit kanonen auf spatzen zu schießen. das der exception-mechanismus effizenz-mäßig in verruf geraten ist, liegt daran, das viele c++-biliotheken unzählige plausibilitätsprüfungen durchführen um im fehlerfall eine exception auszulösen. da sind es aber nicht die exceptions sondern die plausibilitätsprüfungen, die rechenzeit verschlingen.
ein nachteil von c++ ist jedoch, daß der objektorientierte programmierstil zu ausladendem code verleitet. es ist in c++ ja so bequem, inline-funktionen zu schreiben da muß man sich im griff haben. außerdem sind viele c++-bibliotheken ziemlich fett.
fazit: man kann c++ praktisch bedenkenlos auch für zeit/speicherkritische anwendungen einsetzen, muß aber aufpassen, was für bibliotheken man verwendet.
und mit inlines und templates sollte man sich auch zurückhalten.
