C schneller als C++

[SabineWinter]

Hallo,

es heisst ja immer dass C schneller als C++ sei.
Aber das gilt ja nur für das Kompilieren oder ?
Das Programm selbst läuft bei beiden gleich schnell ?

[Mechanics]

Und wegen so einem Quatsch hast du dich angemeldet?

[SabineWinter]

Nee das hört man oft. Und ich will endlich mal Klarheit haben . Ich würde sagen das beschränkt sich rein auf die Kompilierzeit .

[sebi707]

Compilezeit hängt natürlich auch davon ab was man überhaupt compiliert. Einfachen C Code gegen C++ Templatewahnsinn ist wohl der C Compiler schneller durch. Bei der Laufzeit hängt es noch mehr davon ab wie es programmiert ist. Man kann in C langsame Programme schreiben und in C++ auch.

[SabineWinter]

Also wie ich vorher schon feststellte , bezieht sich das nur auf die Kompilierzeit.

[Erhard Henkes]

Hier wurde das Thema in sehr lustiger Form abgehandelt: https://www.c-plusplus.net/forum/162623-full

[5cript]

Ich werfe dazu hier mal was rein: [pls don't flame me :D]
Für µC verwende ich gerade absichtlich C++ für schnellen und super lesbaren Code.
Keine Abstriche machen bei der Abstraktion, und trotzdem genauso kompaktes Assembler erzeugen.

OutputPin<PORTC_ADDR, DDRC_ADDR, 0> RedLed;
RedLed.set();

kompiliert einfach zu:

sbi 39-32,0	 ; Diese und die nächste Zeile
cbi 40-32,0	 ; setzen den Pin als output pin.
sbi 40-32,0	 ; mach die LED an

Was equivalent zum C code ist. Und gleichzeitig das minimale Assembler.

Das ist ein ganz simples Beispiel, aber die Aussage hält für alle komplexeren Beispiele.

[Erhard Henkes]

Ich habe vor einigen Jahren versuchsweise C++ für den µC im Nibo eingesetzt, um das State Pattern realisieren zu können.
http://henkessoft.de/Roboter/Nibo.htm#mozTocId872713
Ist ansonsten am µC oft eine Mischung von C und C++ im Sinne von "C with Classes", wie C++ am Anfang genannt wurde:

// Hilfskonstruktionen
// pure virtual wird dennoch ausgeführt:
extern "C"{
void __cxa_pure_virtual() {} }

// Ersatz für new, new[], delete und delete[] der fehlenden C++-Standard-Bibliothek
void* operator new      (size_t size) { return malloc(size); }
void* operator new[]    (size_t size) { return malloc(size); }
void  operator delete   (void* ptr)   { free(ptr); }
void  operator delete[] (void* ptr)   { free(ptr); }

Da die Speichergrößen in diesem Bereich zunehmen, kann das Sinn machen. Wenn der resultierende Maschinencode ebenfalls kompakt bleibt wie bei C, dann hat man gewonnen.

[PushButton]

Ist die Diskussion nicht irgendwie sinnlos, da ja C eine Teilmenge von C++ ist und ich jederzeit einfach so oder in einer Methode reinen C-Code verwenden kann wenn ich dies möchte?

In C++ hat man doch alle möglichen Paradigmen, in C muss man alles per Hand nachbauen und hat dann nicht mal die Unterstützung des Compilers, sondern muss ständig übelste Selbstdisziplin waren. Dass da viele Fehler vorprogrammiert sind ist doch klar.

Ich bin kein C++ Profi, aber C würde ich nur einsetzen wenn es gar nicht anders geht.

[manni66]

PushButton schrieb:

Ist die Diskussion nicht irgendwie sinnlos, da ja C eine Teilmenge von C++ ist und ich jederzeit einfach so oder in einer Methode reinen C-Code verwenden kann wenn ich dies möchte?

[blurrydetector]

SabineWinter schrieb:

Hallo,

es heisst ja immer dass C schneller als C++ sei.
Aber das gilt ja nur für das Kompilieren oder ?
Das Programm selbst läuft bei beiden gleich schnell ?

Es plenkt schon wieder. Das kann nur blurry333 sein.

[Erhard Henkes]

C eine Teilmenge von C++

Das ist genau der Punkt. Der Übergang ist fließend. Man kann sogar Assemblercode für zeitkritische Stellen einbauen. Was will man mehr?

Die gleichen Argumente fand man bestimmt auch zu Beginn der Sprache C: Assembler ist doch schneller als C.

Wichtiger sind Fragen der Lesbarkeit, Fehleranfälligkeit und Code-Pflege.

[EOP]

PushButton schrieb:

in C muss man alles per Hand nachbauen und hat dann nicht mal die Unterstützung des Compilers, sondern muss ständig übelste Selbstdisziplin waren.

Man sollte nicht nur im Programmieren immer "übelste Selbstdisziplin waren" sonst kommt waren statt wahren dabei raus.

[johan]

Ein C-Programm lässt sich mit Sicherheit schneller übersetzen als ein C++-Programm.

Ein perfektes C++-Programm läuft mit ziemlicher Sicherheit schneller als ein C-Programm. Dies gilt insbesondere für C++ 11 (mit seinen Verschiebe-Operationen), aber auch für normales C++.

Der Grund ist einfach: C++ weiß einfach viel mehr über ein Programm (kann viel mehr Annahmen treffen), als dies ein C-Programm weiß. Dadurch kann ein C++-Compiler viel aggressiver optimieren als ein C-Compiler.

Das gilt wie geschrieben nur für jeweils "optimale" (perfekt optimierende) Compiler für C und C++.

Gilt auch für Templates, denn ein Template konstruiert ja automatisch für jeden neuen Typ neuen Sourcecode (ist ja eigentlich nur ein "intelligentes Preprozessor- Makro") - mit einem Template kann man das erzeugte Binär-File nicht verkleinern. Hat man ein Template für int, long, benutzerdefinierten Typ werden auch für jeden dieser Typen eigener Code generiert (also 3 verschiedene Codes für jeden Typ). Templates sind eben keine echten "Generika".

[TNA]

PushButton schrieb:

Ist die Diskussion nicht irgendwie sinnlos, da ja C eine Teilmenge von C++ ist und ich jederzeit einfach so oder in einer Methode reinen C-Code verwenden kann wenn ich dies möchte?

Das ist nicht ganz richtig. C++ ist zwar so kompatibel mit C wie möglich, aber C ist keine echte Teilmenge von C++. Es gibt C-Programme die sich nicht mit einem C++ Compiler übersetzen lassen, auch wenn das nur sehr spezielle Fälle betrifft. In der Praxis trifft das, was du geschrieben hast auch weitestgehend zu: Ich könnte in C++ wenn ich das möchte so schrieben als wäre es C, habe aber weit mehr Möglichkeiten wenn ich das möchte.

C++-Konstrukte sind oft sehr viel näher am Problem und bieten modernen Compilern damit deutlich bessere Optimierungsmöglichkeiten. Als die Compiler noch schlechter waren sah es vielleicht anders aus.

Gerade Templates bieten die Möglichkeit sehr generischen Code zu schreiben, ohne Typinformationen zu verlieren oder sich das mit zusätzlichen Indirektionen zu erkaufen. Daher ist std::sort in der Regel auch schneller als qsort.

[ant]

TNA schrieb:

Es gibt C-Programme die sich nicht mit einem C++ Compiler übersetzen lassen, auch wenn das nur sehr spezielle Fälle betrifft. In der Praxis trifft das, was du geschrieben hast auch weitestgehend zu: Ich könnte in C++ wenn ich das möchte so schrieben als wäre es C, habe aber weit mehr Möglichkeiten wenn ich das möchte.

Die grössere Anzahl Möglichkeiten macht es für den C++-Compiler aber auch schwieriger, gleichen Code zu optimieren. In C++ müssen (vom Compiler) allerhand Vorsichtsmassnahmen für mögliche Exceptions getroffen werden, was das Binary aufbläht und u.U. langsamer macht.

C++ ist fast "you don't pay for what you don't use" aber eben nicht ganz.

[TNA]

ant schrieb:

In C++ müssen (vom Compiler) allerhand Vorsichtsmassnahmen für mögliche Exceptions getroffen werden, was das Binary aufbläht und u.U. langsamer macht.

C++ ist fast "you don't pay for what you don't use" aber eben nicht ganz.

Exeptions waren lange Zeit eine der zwei Ausnahme von der Regel "you don't pay for what you don't use". Das gilt aber nicht mehr seit C++11. Wenn man an eine Funktion NOEXEPT dran schreibt, gibt es Null Overhead.

[Shade Of Mine]

ant schrieb:

In C++ müssen (vom Compiler) allerhand Vorsichtsmassnahmen für mögliche Exceptions getroffen werden, was das Binary aufbläht und u.U. langsamer macht.

Jein. Das läuft auf modernen Compilern über seperate Maps. dh du zahlst zwar binary size beim Laden der Anwendung aber keine Laufzeit, da der IP genommen wird und Anhand des Wertes IP weiß das Programm was es aufräumen muss.

[PushButton]

@ant
Wieso nicht ganz, soweit ich weiß läuft der Compiler nur einmal durch und wenn man keine Ausnahmen oder virtuelle Methoden nutzt, dann muss man auch nicht dafür "bezahlen" wenn das Programm läuft.

[Shade Of Mine]

PushButton schrieb:

Wieso nicht ganz, soweit ich weiß läuft der Compiler nur einmal durch und wenn man keine Ausnahmen oder virtuelle Methoden nutzt, dann muss man auch nicht dafür "bezahlen" wenn das Programm läuft.

Es kommt darauf an wie Exceptions implementiert sind, prinzipiell geht es dabei um das Stack Unwinding (aufräumen).

Hier was zum lesen: https://magazin.c-plusplus.net/artikel/Modernes Exception-Handling Teil 2 - Hinter den Kulissen