C schneller als C++ ?



  • Schaut euch mal diesen Benchmark an: http://www.bagley.org/~doug/shootout/
    gcc/C schneidet da besser ab als g++/C++, obwohl beide Compiler ja eng verwandt sind. Wie kann das sein?



  • C ist weniger komplex als C++?

    -junix



  • die codes von C und C++ sind nicht aequivalent



  • die Beispiele waren ja simpel. Außerdem sollte der Optimizer bei beiden Compilern fast gleich sein. nur bei dem Exception-Beispiel verstehe ich den Unterschied.



  • da man in c++ alles wie in c machen kann, warens einfach nicht auf speed ausgelegte lösungen, die für c++ eingreiecht wurden. und sowas sollte man doch nicht zu nem speed-test schicken. was soll das?



  • Vor allem sollte man sich anschauen wie die Compiler aufgerufen wurden
    Bei C++ Source: g++ -c -pipe -Wall -O2 -fomit-frame-pointer ...
    Bei C Source: gcc -pipe -Wall -O3 -fomit-frame-pointer

    Ich habe dem Betreiber schon eine email deswegen geschickt... mal sehen.
    Interessant fand ich das Objective Caml und Lisp mit CMUCL als Interpreter so weit vorne lagen.



  • Ich finde das vor allem auch scheiße (pardon), weil so Idioten ihre Software in C statt in C++ schreiben... viel zuviel Freeware ist in C geschrieben.



  • Was ist gegen C einzuwenden?



  • Original erstellt von Luckie:
    Was ist gegen C einzuwenden?

    Dass es unterentwickelt ist? Dass C-Code viel fehleranfälliger is? Dass es keinen Grund gibt, es außerhalb des Kernels zu verwenden, wenn C++ doch mächtiger ist.



  • gute tests können nur sein, wenn man sagt:
    dieses problem ist zu lösen, ihr habt maximal 10k source zu schreiben, macht es, wie ihr wollt.

    meine behauptung ist, daß c++ im allgemeinen deshalb schneller als c wird, weil man die pfiffigeren algorithmen machen kann, auf nem boden, wo man in c sich längst verheddert hätte, weils die dicken sprachmittel nicht hat. daß c++-code von sich aus (naja, mit jahrelanger erfahrung) die probleme unmittelbarer abbildet, und deshalb der mensch es leichter hat, die klugen tricks einzubauen.

    ja, ich weiß, daß diese spielregel einen dicken bonus auf funktionale sprachen wirft, wo man mit ohne viel code wirklich große konzepte implementieren kann. wenn sie an erste stelle kommen, dann ist das verdient. wenn nicht, ist die unmittelbarkeit der main-stream-sprachen noch ausreichend, um bei extremen speed-tests zu gewinnen. (meine prophetische ader sagt: die funktionalen sind so viel geiler zu optimieren und die optimierer werden besser, daß sie noch zu meinen lebzeiten ein zwischenhoch erfahren bei solchen speed-tests und c++ und asm auf breiter front plätten).



  • Erzähl ned so'n Kas Mr. N

    Man kann genauso stabiele und hochwertige Programme in C wie in C++ schreiben.
    Nur weil heute OOP Standard ist, ist Prozedurale Programmierung kein Mist und Fehleranfällig.

    Man muß nur wissen wie man damit umgeht. Kann sein, daß es länger dauert bei der entwicklung größerer Programme. Aber das hat nix mit der Stabilität zu tun.



  • Original erstellt von SnorreDev:
    Man muß nur wissen wie man damit umgeht. Kann sein, daß es länger dauert bei der entwicklung größerer Programme. Aber das hat nix mit der Stabilität zu tun.

    richtig. c ist in guten händen nicht instabiler als c++ in guten händen. und wir sollten nicht anfangen, zu messen, wie laien damit umgehen, sonst würde java auf einmal ne gute sprache sein.
    edit: c++ hat meiner ansicht nach sogar viel mehr gelegenheiten parat, wie man sich aus versehen ein loch ins knie schießt.

    [ Dieser Beitrag wurde am 23.05.2003 um 23:45 Uhr von volkard editiert. ]



  • Noch etwas Mr.N
    Wenn C Fehleranfälliger währe, dann hätte es eben gerade NICHTS in einem Kernel verlohren. Sonst währe das OS ja instabiel.



  • -> Kernel in C++ schreiben und schon gibt es keine Abstürze mehr!



  • natürlich hat C nix im kernel verloren. aber nicht direkt wegen instabilität. es wird ja mehr und mehr langam nach c++ umgesetzt. das dauert halz seine zeit. und da darf man auch nichts überhasten. gutes c ist natürlich erstmal viel besser als hastiges c++.



  • Original erstellt von SnorreDev:
    Noch etwas Mr.N
    Wenn C Fehleranfälliger währe, dann hätte es eben gerade NICHTS in einem Kernel verlohren. Sonst währe das OS ja instabiel.

    Ich meinte eigentlich nicht, dass C selber instabil ist... Sondern, dass es schwer ist, mit C sauberen Code zu machen. (Schon mit C++ extrem schwer)



  • Original erstellt von SnorreDev:
    Noch etwas Mr.N
    Wenn C Fehleranfälliger währe, dann hätte es eben gerade NICHTS in einem Kernel verlohren. Sonst währe das OS ja instabiel.

    Ist Windows wircklich in C geschrieben?



  • @Dimah: Ich kenne den Thread. Trotzdem vertrete ich die Meinung, daß egal ob Kernel oder Anwendungssoftware beides Möglich ist also C oder C++ - ohne Stabilitäts verlust.

    Klar hat C++ Vorteile. Aber um die geht es ja in diesem Thread nicht. Es ging mir nur um die Behauptung, daß C Software instabiel ist und nur im Kernel was zu suchen hat.

    @Mr. N: Sorry, wenn ich es falsch aufgefasst hab, aber so wie du es geschrieben hast, konnte ich auf nix anderes schließen.

    [ Dieser Beitrag wurde am 24.05.2003 um 01:51 Uhr von SnorreDev editiert. ]



  • Original erstellt von TheMummy:
    Interessant fand ich das Objective Caml und Lisp mit CMUCL als Interpreter so weit vorne lagen.

    CMUCL ist nicht nur ein Interpreter.

    Original erstellt von Mr. N:
    Dass es unterentwickelt ist? Dass C-Code viel fehleranfälliger is? Dass es keinen Grund gibt, es außerhalb des Kernels zu verwenden, wenn C++ doch mächtiger ist.

    Was glaubst Du wohl, warum C im sicherheitskritischen Sektor für sicherer als C++ eingestuft wird? Weil alle viel blöder sind als Du, klar.



  • Original erstellt von Daniel E.:
    Was glaubst Du wohl, warum C im sicherheitskritischen Sektor für sicherer als C++ eingestuft wird? Weil alle viel blöder sind als Du, klar.

    Nein. Weil... keine Ahnung warum! Ich erkenne die Logik dahinter nicht. Ist aber wohl die selbe, die dafür sorgt, dass die Leute an Java nicht nur die API schätzen.


Anmelden zum Antworten