Ich will nicht wissen, warum sich OOP trotzdem lohnt!!

Was Doc schon angesprochen hat : du darfst nicht einfach eine normale Funktion aus C mit einer Klassen-Methode aus C++ vergleichen. Denn das ist wie Äpfel und Birnen zu vergleichen. Nicht zuletzt deshalb weil ja auch in C++ Funktionen ohne jede Klassenzugehörigkeit möglich sind, die dann genauso "schnell" wie in C aufgerufen werden . Wer in C++ alles in Klassen schreibt, weil es möglich ist hat das Prinzip nicht verstanden.

Du must also andersrum rangehen : Wie kannst du in C eine Klassenmethode aus C++ mit der gleichen Funktionalität wie in C++ ersetzen? Und da bleibt dir nur einen zusätzlichen Parameter zu verwenden, der ein struct mit Daten aufnimmt. Eben das was in C++ mit this verallgemeinert wird. Und dann sind die Kosten für den Aufruf in C und in C++ wieder genau gleich.

In C++ kommt ja noch die Vererbung und virtuelle Methoden hinzu, die zusätzlich noch Verarbeitungszeit kosten. Aber auch hier gilt : Du must das mit einem Konstrukt in C vergleichen, der die gleiche Funktionaliät (Basisklassen) bietet. Und dann wird sich der vermeintliche Geschwindigkeitsvorteil von C wieder auflösen.

bis bald
akari

Denn im Vergleich ist C schneller als C++

In welchem Vergleich? Was wurde dort denn verglichen?

etzteres ist um einige Dinge wie OOP erweitert worden. Dadurch wurde es nicht unbedingt schneller.

Richtig. Der Compiler braucht jetzt länger, da die Sprachdefinition komplizierter ist.

DocJunioR schrieb:

Dementsprechend ist die OOP eigentlich auch nicht wirklich langsamer

Aber doch so ein bischen, oder wie?

- lediglich der Verwaltungsaufwand ist etwas höher, aber davon bemerkt man als Programmierer kaum was.

Welchen Verwaltungsaufwand meinst du genau?

OOP ist ein Konzept, ein Denk- und Designprinzip. Wie kann das schneller/langsamer sein?

Vergleiche sind eigentlich immer gerade dann interessant, wenn man sie konkretisiert. Allgemeine Fragen wie "macht OOP langsam" werden interessanter, wenn man sie einschränkt.
Eine interessante Fragen wäre z.B. wie sich die Anwendung bestimmter OO-Features in einer Sprache auswirken, also z.B. welche Kosten sie verursachen (für C++ empfehle ich da Stan Lippmans "Inside the C++ Object Model").

Das allgemeinste mir bekannte Problem bezüglich OOP in C++ ist der sogenannte "abstraction penalty". Grob gesagt: Compiler waren/sind nicht immer dazu in der Lage die Verwendung vieler kleiner Objekte (die viele kurze Methoden aufrufen) genausogut zu optimieren, wie äquivalenten Code der "flacher" ist.
Man sollte dies allerdings nicht überbewerten (sondern lieber konkrete Fälle genauer untersuchen), schließlich gab es auch mal Zeiten, als hangeschriebener Assembler-Code immer besser war, als das was der Compiler aus C-Funkionen gemacht hat.