Java vs. C++



  • Zeus schrieb:

    In C++ musst du für Objektorientierung zahlen

    In C++ lässt sich auch statischer Polymorphismus implementieren, der absolut keine Indirektionen zur Folge hat. Moderne C++-Compiler beherrschen außerdem Devirtualization. In C++ zahlt man also unter dem Strich deutlich weniger für Objektorientierung als in anderen OO-Sprachen.
    Außerdem ist dein Argument von Grund auf invalide, denn für Funktionszeiger in C oder für call / jmp zahlt man genauso. Die Abstraktion, die C++ hierbei bietet, beläuft sich lediglich darauf, dass man sich nicht mehr selbst um die Funktionszeigern kümmern muss, wie man es in C müsste. Diese Abstraktion ist in der Tat ohne zusätzliche Kosten; im Gegenteil, sie erlaubt sogar noch besseren Code dank den aufgezählten Optimierungen.

    Zeus schrieb:

    In C++ musst du für Template Mechanismen zahlen

    Ganz klar falsch. "Template-Mechanismen" evaluieren während der Compile-Zeit zu gewöhnlichem C++-Code und werden, wie alles andere, zu nativem Code kompiliert. Ferner erlauben sie Techniken wie Expression Tempaltes oder Spezialisierung, die zu noch performanterem Zielcode führen.

    Zeus schrieb:

    wiederlegen

    Zeus schrieb:

    An wem ist das Adressiert?
    Ich persönlich bin Software Engineer. Ich brauch kein Language War. Außerdem hab ich das Recht eine andere Meinung als irgendwer im Netz zu sein. Copy vs Memcopy ist ja so lächlich weil der Compiler und deren Runtime Implementieren lebendige Software ist, was ist wenn die heutige gcc 5% mehr raushaut?

    Lern zuerst Deutsch, du Analphabet, bevor du hier dein jämmerliches Halbwissen zu Programmiersprachen äußerst.



  • Halsabschneider schrieb:

    Zeus schrieb:

    In C++ musst du für Objektorientierung zahlen

    In C++ lässt sich auch statischer Polymorphismus implementieren, der absolut keine Indirektionen zur Folge hat. Moderne C++-Compiler beherrschen außerdem Devirtualization. In C++ zahlt man also unter dem Strich deutlich weniger für Objektorientierung als in anderen OO-Sprachen.
    Außerdem ist dein Argument von Grund auf invalide, denn für Funktionszeiger in C oder für call / jmp zahlt man genauso. Die Abstraktion, die C++ hierbei bietet, beläuft sich lediglich darauf, dass man sich nicht mehr selbst um die Funktionszeigern kümmern muss, wie man es in C müsste. Diese Abstraktion ist in der Tat ohne zusätzliche Kosten; im Gegenteil, sie erlaubt sogar noch besseren Code dank den aufgezählten Optimierungen.

    Woher kommen die Berechnungen zu devirtualisierung her, holt sie dein C++ Compiler aus eine andere Dimension, damit die keine Kosten haben?

    Halsabschneider schrieb:

    Zeus schrieb:

    In C++ musst du für Template Mechanismen zahlen

    Ganz klar falsch. "Template-Mechanismen" evaluieren während der Compile-Zeit zu gewöhnlichem C++-Code und werden, wie alles andere, zu nativem Code kompiliert. Ferner erlauben sie Techniken wie Expression Tempaltes oder Spezialisierung, die zu noch performanterem Zielcode führen.

    Ja genau der Compiler musst während des Compilezeit Typeinstanziierung von Template berechnen, Instanziierung ausführen und das Ergebnis zurückschreiben - Holt sich der Compiler diese Berechnungen aus eine andere Dimension damit sie nix kosten?



  • Halsabschneider schrieb:

    Moderne C++-Compiler beherrschen außerdem Devirtualization. In C++ zahlt man also unter dem Strich deutlich weniger für Objektorientierung als in anderen OO-Sprachen.

    DO ist im LLVM implementierung und kann von jeden Compilerentwickler für seine Programmiersprache verwenden. Es ist nicht C++ exclusiv!



  • Da klammert sich jemand an die letzten Grashalme. Da sagt er, dass da (zur Compilezeit) sehr wohl Kosten entstehen, um dann danach zu sagen, dass diese Kosten bei C auch entstehen können.
    Mal davon abgesehen, dass man lieber Compiletime-Kosten in Kauf nimmt als Runtime-Kosten (ein Release-Build macht man sowieso viel seltener). Da vermischt jemand ganz gehörig Dinge bzw. tut das absichtlich um auf Teufel komm raus recht behalten zu wollen. Wirklich armselig...



  • ShadowClone schrieb:

    Da klammert sich jemand an die letzten Grashalme. Da sagt er, dass da (zur Compilezeit) sehr wohl Kosten entstehen, um dann danach zu sagen, dass diese Kosten bei C auch entstehen können.
    Mal davon abgesehen, dass man lieber Compiletime-Kosten in Kauf nimmt als Runtime-Kosten (ein Release-Build macht man sowieso viel seltener). Da vermischt jemand ganz gehörig Dinge bzw. tut das absichtlich um auf Teufel komm raus recht behalten zu wollen. Wirklich armselig...

    Erstens, wolltest du die Diskussion nicht mit mir beenden? Warum meldest du dich überhaupt?

    Vorallen, kannst du überhaupt denken? Du schießt dich so sehr ein auf 'kosten'. Das du total vergießt, dass man sich darüber noch über Struktur und Wertigkeit (im Vergleich) reden könnten.

    Außerdem bist du doch gar nicht an eine sinnvolle Diskussion interessiert. Du hast dich schon mit deine ersten Provokation disqualifiziert

    ShadowClone schrieb:

    Von wegen C++ und typsicher!

    int x = 2;
    if (x = 1) {
        std::out << "Na klaro!" << std::endl;
    }
    

    Also Mr.Cpp-Papst, predige C++ weil es eine Ingenieursprache ist :D, aber bitte meide es objektive sich darüber auszutauschen.



  • Verdreh keine Dinge. Der Eingangspost hat Java mit C++ verglichen und es hieß, dass C++ typsicherer als Java sei. In diesem Kontext konnte ich nicht zustimmen, aber ich kann darin zustimmen, dass C++ typsicherer als C ist! – Hat alles Hand und Fuß!



  • ShadowClone schrieb:

    Verdreh keine Dinge. Der Eingangspost hat Java mit C++ verglichen und es hieß, dass C++ typsicherer als Java sei. In diesem Kontext konnte ich nicht zustimmen, aber ich kann darin zustimmen, dass C++ typsicherer als C ist! – Hat alles Hand und Fuß!

    D.h. implizite Typkonvertierung schwächen C++ typensicherheit?
    wenn ja, dann passt dein Post,
    wenn nein, dann ist dein Post unsinn.

    Meine Meinung ist nein.



  • Zeus schrieb:

    ShadowClone schrieb:

    Verdreh keine Dinge. Der Eingangspost hat Java mit C++ verglichen und es hieß, dass C++ typsicherer als Java sei. In diesem Kontext konnte ich nicht zustimmen, aber ich kann darin zustimmen, dass C++ typsicherer als C ist! – Hat alles Hand und Fuß!

    D.h. implizite Typkonvertierung schwächen C++ typensicherheit?

    Ja.



  • cppvsjava schrieb:

    Jetzt schreibe und (ein bisschen) lese ich C++ seit ungefähr 6 bis 8 Jahren. Dann dacht ich mir, ein guter Programmierer, der kann mehr als nur eine Sprache.

    Kann er ja auch. Mit C++ kannst Du eine blockstrukturierte Sprache (C), eine objektorientierte Sprache, eine generische Sprache, eine funktionale Sprache (Template Meta). 4 für einen Preis, ein echtes Schnäppchen.

    cppvsjava schrieb:

    Und dann habe ich Java gemacht.

    Ach Du warst das ?! 😮



  • Vielleicht sollten sich die Gemüter zu dem Thema etwas entspannen und einen Film ansehen 🙂 https://www.youtube.com/watch?v=RnqAXuLZlaE



  • C++ ist langsamer als C, wenn man Objektorientierung benutzt (Konstruktoren, Destruktoren, mehr Daten...). Ansonsten ist das doch C, welches mit einem C++-Compiler compiliert wurde.



  • Eines der größten Probleme wird wohl bleiben, dass die meisten Leute überhaupt nicht in der Lage sind entscheiden zu können, welche Sprache die Richtige für ihr Problem ist.

    MMn. trifft es dieser Spruch am besten:
    "C++ ist eine der meist genutzten Sprache, obwohl diese so scheiße schwer und kompliziert ist."
    Java hingegen ist nur einfach.



  • Gibt es irgendwo *gute* Benchmarks für Java vs. C++, also bei denen das Programm in der jeweiligen Sprache immer bestmöglichst die Sprachfeatures ausnutzt (nicht so wie der olle c't-Test, wo Strings in C++ per value (!) übergeben wurden)?



  • grundsätzlich gilt, dass die javavm einen interpreter darstellt und dass dieser interpreter naturgemäß einfach mehr rechenzeit beansprucht, als opcodes.

    da brauchst du keine benchmarks für.



  • HansKlaus schrieb:

    grundsätzlich gilt, dass die javavm einen interpreter darstellt und dass dieser interpreter naturgemäß einfach mehr rechenzeit beansprucht, als opcodes.

    Die JVM hat auch einen JIT Compiler aus dem Opcodes rauspurzeln. Die Begründung passt also nicht.



  • Kritischer Geist schrieb:

    Gibt es irgendwo *gute* Benchmarks für Java vs. C++, also bei denen das Programm in der jeweiligen Sprache immer bestmöglichst die Sprachfeatures ausnutzt (nicht so wie der olle c't-Test, wo Strings in C++ per value (!) übergeben wurden)?

    *push*



  • Tobiking2 schrieb:

    HansKlaus schrieb:

    grundsätzlich gilt, dass die javavm einen interpreter darstellt und dass dieser interpreter naturgemäß einfach mehr rechenzeit beansprucht, als opcodes.

    Die JVM hat auch einen JIT Compiler aus dem Opcodes rauspurzeln. Die Begründung passt also nicht.

    class jvm
    {
    stack<call_frame> callStack;
    stream<byte_code> byteCode;
    mapped_file<native_code> nativeCode;
    map<byte_code*, native_code*> codeCache;
    }
    

    Ach wieso nicht? Nur weil Opcodes generiert wird?



  • Kritischer Geist schrieb:

    Kritischer Geist schrieb:

    Gibt es irgendwo *gute* Benchmarks für Java vs. C++, also bei denen das Programm in der jeweiligen Sprache immer bestmöglichst die Sprachfeatures ausnutzt (nicht so wie der olle c't-Test, wo Strings in C++ per value (!) übergeben wurden)?

    *push*

    https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=java&lang2=gpp



  • benchm schrieb:

    Kritischer Geist schrieb:

    Kritischer Geist schrieb:

    Gibt es irgendwo *gute* Benchmarks für Java vs. C++, also bei denen das Programm in der jeweiligen Sprache immer bestmöglichst die Sprachfeatures ausnutzt (nicht so wie der olle c't-Test, wo Strings in C++ per value (!) übergeben wurden)?

    *push*

    https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=java&lang2=gpp

    Danke! Da schneidet ja C++ immer deutlich besser als Java ab. 🙂


  • Mod

    Kritischer Geist schrieb:

    benchm schrieb:

    Kritischer Geist schrieb:

    Kritischer Geist schrieb:

    Gibt es irgendwo *gute* Benchmarks für Java vs. C++, also bei denen das Programm in der jeweiligen Sprache immer bestmöglichst die Sprachfeatures ausnutzt (nicht so wie der olle c't-Test, wo Strings in C++ per value (!) übergeben wurden)?

    *push*

    https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=java&lang2=gpp

    Danke! Da schneidet ja C++ immer deutlich besser als Java ab. 🙂

    Es ist durchaus bekannt, dass C++ Programme etwas schneller als Javaprogramme laufen. Man nutzt Java aber auch nicht, wenn es einem darum geht, das performanteste Programm zu schreiben. Java nutzt man aus anderen Gründen, zum Beispiel könnte die Infrastruktur im Umfeld der Sprache relevant sein und das verfügbare Know-How diesbezüglich. In Sachen Performance reicht es für Java völlig aus, halbwegs in der gleichen Liga wie C++ zu spielen. Wenn Javaprogramme grundsätzlich >10 mal langsamer als C++ Programme wären, dann wäre das für Java wohl ein Problem. So ist es aber nicht.


Anmelden zum Antworten