von Java nach C++



  • Ich glaube nicht, dass es gutes Material zu den Unterschieden von C++ und Java gibt.

    Wenn Du aber Java kannst, lies ein Grundlagenbuch von C++ durch. Wenn Du die Dinge von Java kennst, kannst Du dort ja schneller lesen / es überfliegen und wirst dadurch auch kaum Zeit verlieren. Du wirst aber garantiert sehen, was bei C++ anders als bei Java ist und auch keinen der Unterschiede überspringen (was eben bei irgendeinem Artikel zu den Unterschieden passieren könnte).

    Auch bei Architektur betreibt man C++ anders, man setzt viele Patterns anders um, baut häufig auf freie Funktionen, wo man in Java unnötigerweise eine Klasse benutzt und hat auch keine statischen Klassen wie Math oder so ein Käse. Und dann gibt es eben den großen Bereich der Templates, den man in Java so gut wie gar nicht (Generics können ja nichts) hat.

    ➡ Java-Wissen alleine reicht nicht aus, um nur über die Unterschiede zu versuchen C++ zu lernen. Damit erschließt Du Dir lediglich einen Bruchteil und viel automatisch falsch.



  • Ich will hier nun wirklich keine übliche "Java ist sch..."-Diskussion anfangen, aber darauf will ich dann doch mal antworten.

    idx schrieb:

    Ich weiß das Java einem ne Menge abnimmt, auch an Freiheiten, deswegen ist es aber noch lange nicht Müll.

    Wenn man mit Java programmiert, dann sind einige Punkte von vorneherein klar:
    - man benötigt die JVM (die ich jetzt schon seit Jahren nicht mehr auf meinen Computer lasse - wenn ich bei der Installation eines Programms merke, dass das Programm die JVM braucht, installier ich es nicht, gleiches gilt für das Java-Browser-Plugin, das regelmäßig für schwere Sicherheitslücken sorgt)
    - man ist vollständig abhängig von Oracle und deren Firmenpolitik
    - Java wird somit finanziell ausgeschlachtet, was bei anderen Programmiersprachen wie C oder C++ nicht der Fall ist
    - es gibt neben der Oracle JVM noch diese OpenJDK, aber ob die tatsächlich eine Alternative ist, weiß ich nicht
    - die Programme werden, so gut sie noch geschrieben sind, verhältnismäßig langsam laufen
    - Java bedeutet: ein bisschen Portabilität zugunsten der Geschwindigkeit
    - Java lässt sich nicht zur Betriebssystem-Entwicklung einsetzten

    Das alles sind für mich Punkte, die eine eindeutige Sprache sprechen. Vor allem die Sache mit der Performance und der JVM sind halt schlecht. (bezüglich Performance: -> Minecraft)



  • Na, das ist so alles nicht ganz richtig - ich denke der Grund warum viele C Entwickler Java verabscheuen ist, dass es wirklich mal schlecht und langsam war, aber das ist definitv vorbei. (Ich möchte jetzt auch nicht bashen - es gibt ja Gründe warum ich mich für C++ interessieren, sonst wär ich nicht hier, aber viele haben doch eine mir unverständliche Abneigung gegebnüber Java)

    - man benötigt die JVM (die ich jetzt schon seit Jahren nicht mehr auf meinen Computer lasse - wenn ich bei der Installation eines Programms merke, dass das Programm die JVM braucht, installier ich es nicht, gleiches gilt für das Java-Browser-Plugin, das regelmäßig für schwere Sicherheitslücken sorgt)

    Man benötigt eine JVM das stimmt, dafür hat man halt Platformunabhängigkeit ohne auch nur eine Zeile Code zu ändern oder gar neu kompilieren zu müssen mit den Nachteilen der Sicherheit. Das Browser Plugin muss man nicht installieren, mach ich auch nicht, weil Pulgins nix im Browser zu suchen haben (vor allem Flash nicht)

    - man ist vollständig abhängig von Oracle und deren Firmenpolitik
    - Java wird somit finanziell ausgeschlachtet, was bei anderen Programmiersprachen wie C oder C++ nicht der Fall ist

    Jeder kann theoretisch seine eigene VM schreiben, siehe OpenJDK oder Googles VM die auf Android läuft (Android Apps sind hauptsäch Java, es sei denn man verwendet das ndk) Wobei ich zugeben muss dass Oracle mit ihrem Patenzug gegen das Böse generell in der Java Community negativ dasteht. Sun war da um Meilen eine bessere Firma, generell was die ganze Politik um Java anging

    - es gibt neben der Oracle JVM noch diese OpenJDK, aber ob die tatsächlich eine Alternative ist, weiß ich nicht
    Es ist halt die Quelloffene Version - ursprünglich noch von Sun als OpenSource freigegeben. Ist mittlerweile Standard in fast jeder Linux Distribution

    - die Programme werden, so gut sie noch geschrieben sind, verhältnismäßig langsam laufen
    Seit Java 1.5 generiert der JIT zur Laufzeit Maschinencode. Langsam ist Java eigentlich nur <= 1.4

    - Java bedeutet: ein bisschen Portabilität zugunsten der Geschwindigkeit
    Es heißt auch Tage und Jahre weniger Arbeit da es seeeehr viele (augereifte) Frameworks für nur alle erdenklichen Situationen gibt.
    Wenn man eine Zeit mit Java arbeitet weiss man das auch zu schätzen

    - Java lässt sich nicht zur Betriebssystem-Entwicklung einsetzten
    Ich glaube ein Betriebssystem entwickeln auch die wenigsten 😉 aber ja, du hast recht - dafür wurde es auch nicht designed.

    Das alles sind für mich Punkte, die eine eindeutige Sprache sprechen. Vor allem die Sache mit der Performance und der JVM sind halt schlecht. (bezüglich Performance: -> Minecraft)
    Was haben alle immer gegen Minecraft?, mal ehrlich ich finde es nicht langsam...

    Ich habe aber auch so meine Hass Sprachen, alles was keine Typen Sicherheit bietet, z.B. PHP, Perl, JavaScript

    Trotz allem werde ich dann wohl von null anfangen, wobei die Tutorials die ich bisher gesehen haben auch wirklich nicht toll waren; vielleicht bin ich auch zu ungeduldig, aber da muss ich wohl durch.
    Wenn ich mal ein bisschen C++ kann werde ich mal nen Vergleich machen in Sachen Geschwindigkeit C++ und Java... 😉



  • Ein bisschen C++ können reicht nicht für nen Benchmark, dann kommen wieder irgendwelche ineffizienten Codes raus, weil man den Code einfach nur mehr oder minder pastet.

    Ich finde Java und C++ haben beide ihre Existenzberechtigungen. Die Performance von Java ist meistens irrelevant. Ich finde die Oberfläche halt zum Wegwerfen und habe dort oft den Eindruck, dass sie langsamer ist - aber auch hier können das meinetwegen alte VMs/alter Code sein.

    Ansonsten ist mir die Sprache immer noch zu aufgebläht, man kann Dinge, die nicht gerade mit Serialisierung zu tun haben, in C++ kürzer schreiben, finde ich. Signal-Slot-Konzepte finde ich weit schöner als jedes Mal ObServer-Interfaces implementieren zu müssen.

    Auf der anderen Seite sind Java-Programme auf Grund der Serialisierbarkeit weit besser für Geschäftsanwendungen geeignet, sodass man leicht riesen Frameworks aufbauen kann, welche einem rasch alle notwendigen Objekte erstellen, um mit wenig Aufwand eine Klasse auf eine Datenbanktabelle abzubilden. In C++ muss man sich den ganzen Serialisierungs-Code immer von Hand schreiben, das empfinde ich schon als ätzend.

    Portabilität finde ich unwesentlich. Da nutzt man in C++ die entsprechenden Bibliotheken und ist genau so gut dran. Natürlich gibt es Teile, die man dann doch BS-spezifisch nutzt, sodass der Code fürs Portieren umgeschrieben werden muss. Das sind dann aber die Feinheiten, die ich bei Java auch vermisse (jedoch habe ich hier kein Beispiel).

    Na ja und die vielen Bibliotheken für Java sind eben durchaus ein gutes Argument. Die Sprache selbst ist imo hoffnungslos unterlegen. Gäbe es für C++ entsprechend viele und gut ausgebaute Bibliotheken (sauber mit C++11-Features gestrickt), dann hätte Java in meinen Augen keine Daseinsberechtigung mehr für neue Projekte und unter Vernachlässigung der darin ausgebildeten Leute.

    Aber das kann man eben nicht einfach Mal nachliefern, das ist kein trivialer Vorteil.



  • Ich weiß das Java einem ne Menge abnimmt, auch an Freiheiten, deswegen ist es aber noch lange nicht Müll.

    Das ist ja wohl der Witz des Jahrhunderts.
    Es ist nämlich gerade umgekehrt.

    Wo man mit Java mit try-catch-finaly herumfrickeln darf, weil der tolle GC zwar den Speicher aufräumt den Speicher aufräumt, sonst aber nichts.
    Lässt man unter C++ einfach die Destruktoren für sich arbeiten ( Stichwort RAII)

    PrintWriter file;
    try {
      file = new PrintWriter("Hallo.txt");
      file.println("Hallo Welt!");
    } catch(Exception e) {
    } finally {
      file.close();
    }
    

    Viel kürzer gehts in C++

    std::ofstream file("Hallo.txt");
     file << "Hallo Welt!\n";
    


  • Platformunabhängigkeit

    Irrtum, Java ist die Plattform. Keine JVM, kein Java. Waehrend es fuer fast alles einen C-Compiler gibt, gibt es wenig Plattformen fuer die JVM.

    kann theoretisch seine eigene VM schreiben

    Tolles Argument. Es macht aber keiner.

    Seit Java 1.5 generiert der JIT zur Laufzeit Maschinencode. Langsam ist Java eigentlich nur <= 1.4

    Hat OpenJDK auch einen JIT-Compiler?

    Wenn ich mal ein bisschen C++ kann werde ich mal nen Vergleich machen in Sachen Geschwindigkeit C++ und Java...

    Bitte nicht.



  • knivil schrieb:

    kann theoretisch seine eigene VM schreiben

    Tolles Argument. Es macht aber keiner.

    java impliziert eigentlich eine platformunabhaengigkeit <= c++ dadurch 🙂

    Wenn ich mal ein bisschen C++ kann werde ich mal nen Vergleich machen in Sachen Geschwindigkeit C++ und Java...

    Bitte nicht.

    auch dagegen. c++ ist das was der programmierer draus macht, nimmt dir nicht wie java viele dinge ab und hindert dich nicht wie java an vielen dingen. entsprechend impliziert das, schlechter programmierer -> c++ langsammer, guter programmierer -> c++ schneller, genialer programmierer -> weiss dass java nicht wegen performance existiert und performance-vergleiche unnoetig sind.



  • @Soller Das wird doch erst richtig lustig wenn man 3 Dateien auf einmal öffnet. 😉
    https://ideone.com/qF5lnZ



  • idx schrieb:

    Na, das ist so alles nicht ganz richtig - ich denke der Grund warum viele C Entwickler Java verabscheuen ist, dass es wirklich mal schlecht und langsam war, aber das ist definitv vorbei.

    Trotzdem, ein Java-Programm wird nie an die Schnelligkeit eines C-Programms rankommen.

    idx schrieb:

    Man benötigt eine JVM das stimmt, dafür hat man halt Platformunabhängigkeit ohne auch nur eine Zeile Code zu ändern oder gar neu kompilieren zu müssen mit den Nachteilen der Sicherheit. Das Browser Plugin muss man nicht installieren, mach ich auch nicht, weil Pulgins nix im Browser zu suchen haben (vor allem Flash nicht)

    Du hast recht, mit dem Flash-Plugin verhält es sich ähnlich. Aber es gibt jetzt HTML5, das hoffentlich dieses Flash-Zeugs überflüssig macht.
    Zurück zur JVM: Es wird häufig behauptet, dass Java plattformunabhängig sei. Das ist schon richtig, aber man muss eben daran denken, WARUM und WIE diese Plattforumunabhängigkeit entsteht. Java-Quellcode wird mit einem eigenen Compiler in ein eigenes Bytecode-Format übersetzt. Dieses Bytecodeformat wird von der JVM interpretiert, und genau hier ist die plattformunabhängigkeit. Die JVM muss für jede erdenkliche Plattform umgemodelt und neu geschrieben werden, d.h. irgendein Programmierer bei Oracle schuftet hart, dass die JVM auf der Zielplattform läuft. Mit dem Ziel: nicht du als Java-Programmierer kümmerst dich um die Plattformumabhängigkeit, sondern irgendein C- oder C++-Programmierer bei Orace. Das Problem namens "Plattformunabhängigkeit" wird also nur verlagert.

    idx schrieb:

    Es ist halt die Quelloffene Version - ursprünglich noch von Sun als OpenSource freigegeben. Ist mittlerweile Standard in fast jeder Linux Distribution

    Es ist aber bei fast keiner vorinstalliert, und das ist auch gut so. Ein Großteil der Linux-Programme sind stinknormale, native Programme, die mit dem GCC direkt von C-Quelltext kompiliert werden.

    idx schrieb:

    Seit Java 1.5 generiert der JIT zur Laufzeit Maschinencode. Langsam ist Java eigentlich nur <= 1.4

    Wie gesagt, ein natives Programm ist IMMER schneller als ein Java-Programm. Egal wie gut oder schnell der Interpreter ist.

    P.S.: Kommt das nur mir so vor, oder ist das Zitiersystem dieses Forums irgendwie lästig?



  • Soller schrieb:

    Ich weiß das Java einem ne Menge abnimmt, auch an Freiheiten, deswegen ist es aber noch lange nicht Müll.

    Das ist ja wohl der Witz des Jahrhunderts.
    Es ist nämlich gerade umgekehrt.

    Wo man mit Java mit try-catch-finaly herumfrickeln darf, weil der tolle GC zwar den Speicher aufräumt den Speicher aufräumt, sonst aber nichts.
    Lässt man unter C++ einfach die Destruktoren für sich arbeiten ( Stichwort RAII)

    PrintWriter file;
    try {
      file = new PrintWriter("Hallo.txt");
      file.println("Hallo Welt!");
    } catch(Exception e) {
    } finally {
      file.close();
    }
    

    Viel kürzer gehts in C++

    std::ofstream file("Hallo.txt");
     file << "Hallo Welt!\n";
    

    Watt hat der GC denn mit nem try catch zu tun das musst du mir mal erklären 🙂

    try catch finally gibts auch in c++ und sollte in kritischen Teilen auch verwendet werden.
    Was ist passiert in deinem Beispiel, wenn es nicht möglich ist Hallo.txt zu erzeugen, oder wenn keine Berechtigung besteht oder was auch immer? Der Code müsste dir um die Ohren fliegen oder was?
    Was ist mit ofstream muss er nicht geschlossen werden oder geflushd, passiert das automatisch?

    Das ist kein gebashe, sondert ernst gemeint, mich würde interessieren, was da passiert.



  • Lerne C++! Komme wieder in 5 Jahren.



  • knivil schrieb:

    Lerne C++! Komme wieder in 5 Jahren.

    Oh, ersteres hatte ich vor, deswegen hatte ich mich hier angemeldet.
    Warum soll ich jetzt wieder gehen?

    Mal davon abgesehen dass ich diesen Thread mit einer einfach Frage ohne gebashe gestartet habe wurde nur auf mich eingeprügelt, weil ich das Wort Java erwähnt habe - was soll das? Seid ihr alle als fertige unantastbare Meister vom Himmel gefallen.

    Habe mir grad das C++ Primer Buch bestellt ich bin schon sehr gespannt wie C++ so ist; vielleicht werde ich ja auch noch nen richtig Fan, aber ich werde deswegen niemals andere nieder machen oder sagen dass sie sich verpissen sollen, nur weil das Wort Java oder PHP oder sonst was erwähnt wird.



  • Soller schrieb:

    Wo man mit Java mit try-catch-finaly herumfrickeln darf, weil der tolle GC zwar den Speicher aufräumt den Speicher aufräumt, sonst aber nichts.
    Lässt man unter C++ einfach die Destruktoren für sich arbeiten ( Stichwort RAII)

    PrintWriter file;
    try {
      file = new PrintWriter("Hallo.txt");
      file.println("Hallo Welt!");
    } catch(Exception e) {
    } finally {
      file.close();
    }
    

    Viel kürzer gehts in C++

    std::ofstream file("Hallo.txt");
     file << "Hallo Welt!\n";
    

    Ab Java 7 gibt es ein "try with resources", in dem einen das Schließen der Resourcen auch abgenommen wird.

    Dein Beispiel sollte da dann ungefähr so aussehen:

    try (PrintWriter file = new PrintWriter("Hallo.txt")){
       file.println("Hallo Welt!");
    }
    


  • cooky451 schrieb:

    @Soller Das wird doch erst richtig lustig wenn man 3 Dateien auf einmal öffnet. 😉
    https://ideone.com/qF5lnZ

    Ja, ne ist klar.

    public class JavaApplication1 {
    
        /**
         * @param args the command line arguments
         */
        public static void main(String[] args) {
            try(PrintWriter file1 = new PrintWriter("file1.txt");
                PrintWriter file2 = new PrintWriter("file2.txt");
                PrintWriter file3 = new PrintWriter("file3.txt")    ) {
            } catch (Exception ex) {            
            }
        }
    }
    


  • Und man braucht dann kein close() mehr?



  • cooky451 schrieb:

    Und man braucht dann kein close() mehr?

    Yup, und wie Gregor schon verlinkt hat:

    http://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html schrieb:

    The try-with-resources statement is a try statement that declares one or more resources. A resource is an object that must be closed after the program is finished with it. The try-with-resources statement ensures that each resource is closed at the end of the statement. Any object that implements java.lang.AutoCloseable, which includes all objects which implement java.io.Closeable, can be used as a resource.



  • Ab Java 7 gibt es ein "try with resources", in dem einen das Schließen der Resourcen auch abgenommen wird

    Richtig!
    Aber Java kann es erst seit Version 7, währen RAII jeder popelige C++ Compiler der letzten 30 Jahre beherrscht.



  • Wenn so ein C++ vs. Java Flamewar auftaucht, schaue ich manchmal im Language Shootout, wie es inzwischen bei der dortigen willkürlichen Wahl von Microbenchmarks aussieht:

    http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=gpp&lang2=java&data=u64q

    Um es kurz zusammenzufassen:

    1. Bei den benötigten Codezeilen scheinen sich die beiden Sprachen nicht besonders stark zu unterscheiden.

    2. C++ Programme sind typischerweise etwas schneller als Javaprogramme, in der Testmenge an Programmen auf der Seite geht das von einem Faktor 1.0 bis zu einem Faktor 2,4.

    3. Javaprogramme benötigen deutlich mehr Speicher. Das ist vielleicht der größte Nachteil von Java.



  • Zeus schrieb:

    cooky451 schrieb:

    @Soller Das wird doch erst richtig lustig wenn man 3 Dateien auf einmal öffnet. 😉
    https://ideone.com/qF5lnZ

    Ja, ne ist klar.

    public class JavaApplication1 {
    
        /**
         * @param args the command line arguments
         */
        public static void main(String[] args) {
            try(PrintWriter file1 = new PrintWriter("file1.txt");
                PrintWriter file2 = new PrintWriter("file2.txt");
                PrintWriter file3 = new PrintWriter("file3.txt")    ) {
            } catch (Exception ex) {            
            }
        }
    }
    

    Hallo, warum verwendest du das "@" in "@param"?
    Diesen Comment-Style habe ich schon öfters gesehen. Wie heißt das genau?



  • -Nachfrage- schrieb:

    Hallo, warum verwendest du das "@" in "@param"?
    Diesen Comment-Style habe ich schon öfters gesehen. Wie heißt das genau?

    Das sind Javadoc-Kommentare. Javadoc ist ein Werkzeug, das Dir aus solchen Kommentaren eine hübsche html-Doku baut. ...ähnlich wie zum Beispiel Doxygen.


Anmelden zum Antworten