Nun meine Fragen dazu:

Was kosten virtuelle Funktionen wirklich(vtable und co.)?

Was kosten Exceptions wirklich und wann sollte man sie einsetzen? Java Programmierer benutzen Exceptions für jede Art der Fehlerbehandlung, mir kommen aber Exceptions zu "klotzig" vor. Wann sind C-like Fehlerrückgabewerte von Funktionen den Exceptions vorzuziehen? Ist das überhaupt C++-like?

Bringt die expliziete Verwendung von register heutzutage noch Vorteile?

Wie performant sind die C++ Standardfunktionen? Befinde ich mich noch im C++ Standard, wenn ich die C Funktionen wie memset, strcat, etc. verwende?

Danke für Eure Antworten!

Bringt die expliziete Verwendung von register heutzutage noch Vorteile?

Das sagt dir die Doku deines Compilers.
Meistens heißt es da: "Dieses Schlüsselwort wird ignoriert."
Bei Embedded kann es anders aussehen. Schaden wird es nicht.

Wie performant sind die C++ Standardfunktionen? Befinde ich mich noch im C++ Standard, wenn ich die C Funktionen wie memset, strcat, etc. verwende?

Ja.
Da die Standardfunktionen meist von den selben Leuten, wie der Compiler
stammt, ist die Chance groß, dass sie wissen, mit welchen Tricks sie sie performant gestalten. Oft übernimmt der Compiler schon von sich aus Funktionen wir malloc, memset etc. (eingebaut)

Was kosten virtuelle Funktionen wirklich(vtable und co.)?

Verglichen mit einfachen calls sind virtuelle calls relativ teuer. Aber mit der heutigen Hardware würde ich sagen, dass man da keinen extremen Unterschied bemerken würde (ausser man hat vtable-calls in verschachtelten Schleifen und viele Iterationen).

Was kosten Exceptions wirklich und wann sollte man sie einsetzen? Java Programmierer benutzen Exceptions für jede Art der Fehlerbehandlung, mir kommen aber Exceptions zu "klotzig" vor. Wann sind C-like Fehlerrückgabewerte von Funktionen den Exceptions vorzuziehen? Ist das überhaupt C++-like?

Im Prinzip ist der Ganze Exception-Mechanismus auch nur ein strukturiertes goto; nur müssen hier die Sprungmarken in die Aufgerufene Funktion "mitgenommen" werden. Im Normalfall reicht es, wenn du Exceptions nur dann verwendest, wenn wirklich etwas Aussergewöhnliches passiert. Sonst würde ich bei Rückgabewerten bleiben.

Bringt die expliziete Verwendung von register heutzutage noch Vorteile?

Eher nicht. Visual C++ 8.0 zum Beispiel berücksichtigt das nicht mehr (baut aber selbstständing SSE2-Instruktionen und solches Zeug ein). Soweit ich das weiss, gibt es dieses Schlüsselwort in C++ sowieso nur der C-Kompatibilität wegen.

Letztlich hilft hier aber nur messen, da das immer auch vom konkreten Programm abhängig ist (wie oft werden Exceptions geworfen, wieviel Stack-Unwinding findet statt, wie sieht die alternative Fehlerbehandlungsstrategie aus usw.).
Ähnliches gilt auch für virtuelle Funktionen. 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.

Guckst du auch hier:
http://www.eventhelix.com/RealtimeMantra/Basics/ComparingCPPAndCPerformance.htm
http://www.eventhelix.com/RealtimeMantra/Basics/ComparingCPPAndCPerformance2.htm

MfG SideWinder

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.