performance von C und gegenüber C++



  • Wenn C++ wirklich so performant wäre, wie es C-Compilate unbestritten sind, stellt sich die Frage, warum gängige Betriebssysteme noch immer in C und nicht in C++ geschrieben werden.



  • gast i.s.b.
    ***********

    ich vermute mal, weil die vielleicht keinen bock haben ihre hunderttausende von quellcodezeilen umzuschreiben? man könnte das ja alles nach c++ portieren, nur siehts dann immernoch wie C aus 😉 sprich man braucht auch ne komplette redesignphase/neuschreibphase...und rechtfertigt das den aufwand? ich vermute weiter wenn du nen OS schreibst brauchste ja auch irgendwann ein compiler für dein system und ein C compiler ist da glaub ich schneller entwickelt als C++ (zumindest ist der C standard von den ausmaßen sicher nur ein drittel vom c++ standard)

    tschööö

    tt



  • Gast ist schon belegt schrieb:

    Wenn C++ wirklich so performant wäre, wie es C-Compilate unbestritten sind, stellt sich die Frage, warum gängige Betriebssysteme noch immer in C und nicht in C++ geschrieben werden.

    und was ist mit win2000 (drauf aufbauend winxp, win server 2003, win longhorn usw.)?

    klar ist linux noch in c und windows würde auch noch in c sein, wenn ms nicht so viel geld hätte und sich gedacht hatt: ok wir vergessebn den win9x & winnt code und schreiben alles neu, aber diesmal sauber und in c++

    mathik schrieb:

    und warum wird denn überhaupt noch so viel in C programmiert? siehe z.b. die ganze software unter Linux (apache, samba, usw.) .

    weil sie keine zeit haben die software neu in c++ zu schreiben



  • Hallo,
    C++ != Objektorientier. Das sollte man immer bedenken, bevor man irgendwelche Aussagen trifft.

    wieso wird im embedded bereich denn immer noch so oft in C programmiert?

    Immer langsam. So schnell geht das mit dem Wechsel nicht. Es hat viele Jahre gedauert, bis im Embedded-Bereich im Großen Stil C statt Assembler benutzt wurde. Und es wird viele Jahre dauern, bis C++ statt C verwendet wird. Wenn man sich aber mal ein bischen in der Embedded-Literatur-Welt umschaut, wird man feststellen, dass C++ immer häufiger ein Thema wird (siehe z.B. Embedded Systems Programming)

    Eins sollte aber relativ klar sein: Niemand der 4k Speicher zur Vrfügung hat wird sein Steuerungsprogramm schön Objektorientiert aufbauen, fein mit Hierarchien, virtuellen Methoden und vielen kleinen Objekten. Die OOP hat gute Anwendungsgebiete, aber nicht alles was programmiert werden muss, sollte oo programmiert werden. Dennoch: auch wenn man auf oop verzichtet hat C++ gegenüber C Vorteile.

    im internet finde ich zu dem thema leider auch nichts. vielleicht kannst du mir ja einen link posten, wenn du eins hast

    Nachher vielleicht. Jetzt muss ich los.



  • Ein wichtiger Grund ist auch, dass C++-Compiler um Größenordnungen schwerer zu entwickeln sind als C-Compiler, und zwar zwar hauptsächlich wegen der komplizierteren Semantik. Kleine Klitschen, die C-Compiler für embedded-Systeme bauen, kümmern sich lieber um Code-Optimierung als um Name-Lookup oder Überladungsauflösung.



  • Bashar schrieb:

    [..] Kleine Klitschen, die C-Compiler für embedded-Systeme bauen, kümmern sich lieber um Code-Optimierung als um Name-Lookup oder Überladungsauflösung.

    Jetzt hätt ich einmal auch nen gutes Argument gehabt um mitzureden und dann im
    letzten Posting ist mir einer zuvorgekommen 😞 😉



  • @Shade
    das Argument mit den Templates verstehe ich nicht

    #include <cstdio>
    
    template<class T> T foo(int c) { return c/static_cast<T>(2); };
    
    int main() {
      std::printf("%f\n",foo<float>(5));
      std::printf("%d\n",foo<int>(5));
    }
    
    #include <stdio.h>
    
    int foo_int(int c) { return c/2; }
    float foo_float(int c) { return c/(float)2; }
    
    int main() {
      printf("%f\n",foo_float(5));
      printf("%d\n",foo_int(5));
      return 0;
    }
    

    sollte ja die gleiche Code größe ergeben. Dachte Templates sind nützlich, weil man Code spart und nicht für jeden Fall alles neu implementieren muss (und noch ein paar andere Tricks). Aber ich denke nicht, dass die Binarys deswegen kleiner werden.

    zB dass C++ langsamer sei

    Ich denke eher, dass die Leute in dem Fall mehr an die Binary größe denken, aber die ist ja bei C++ gleich (wenn man die C++ Standard-Library nicht linkt, die auf Embedded Systemen ja eh nicht vorhanden ist)



  • kingruedi schrieb:

    @Shade
    das Argument mit den Templates verstehe ich nicht

    weil dus falsch verstanden hast 😉

    Ich meine nur bei Member Funktionen (habe ich nicht explizit geschrieben, weil ich dachte dass es klar ist - aber jetzt wo ichs nochmal gelesen habe -> du hast recht, ist nicht klar ersichtlich).

    Denn es werden nur die Member Funktionen von Template Klassen instanziiert, die auch gebraucht werden, die anderen nicht. Bei 'normalen' non-Template Klassen werden alle Member Funktionen instanziiert.

    Dies ist natürlich normalerweise ziemlich egal - aber gerade auf Embedded Systemen kann es Vorteile bringen.



  • Wer sagt denn, dass alle Memberfunktionen von nicht-Template-Klassen "instanziiert" werden müssen? Es gibt kein konformes Programm, dass feststellen kann, dass eine Memberfunktion nicht instanziiert wurde, also steht es dem Übersetzer frei, die Definition im Executable nicht einzubinden, wenn sie nicht angesprochen wird.





  • Das mag bei dem einen Compiler so sein. Generell sagen kann man das mit Sicherheit nicht. Die Frage ist nur, ob der Compiler (bei Templates) oder der Linker (bei nicht-Templates) schlau sein muss.
    Dass Memberfunktionen von Templates nicht instanziiert werden, hat eigentlich nur den Effekt, dass in diesen Funktionen nicht nach Fehlern gesucht wird. Beispiel vector<T>::resize für ein T ohne Standardkonstruktor -- macht nichts, solange resize nicht aufgerufen und damit instanziiert wird.



  • mathik schrieb:

    im internet finde ich zu dem thema leider auch nichts. vielleicht kannst du mir ja einen link posten, wenn du eins hast

    HumeSikkins schrieb:

    Nachher vielleicht. Jetzt muss ich los.

    So, jetzt bin ich wieder da.

    Teste mal std::sort gegen qsort()

    Bitte schön

    OOP erzeugt nicht zwangsläufig Overhead - gute compiler optimieren da 'wie sau'

    Stichwort: Abstraction Penalty

    Geschwindigkeit dank Templates:
    Bitte schön
    Bitte schön

    Ein paar simple Vergleiche:
    Comparing C++ and C Performance I

    Comparing C++ and C Performance II



  • Agilent verwendet meines Wissens im Embedded-Bereich fast ausschließlich C++.
    Okay, was ich bis jetzt gesehen habe sieht eher nach C+ aus, aber egal.
    Und die scheinen recht glücklich mit ihrer Wahl zu sein.

    MFG Jester



  • (denke ich werd den Thread später in die FAQ packen, vorallem die Links von Hume sehen sehr gut aus)


Anmelden zum Antworten