von Java nach C++

Eisflamme

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";

knivil

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.

cooky451

@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?

idx

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.

knivil

Lerne C++! Komme wieder in 5 Jahren.

idx

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.

Gregor

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!");
}

Zeus

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) {            
        }
    }
}

cooky451

Und man braucht dann kein close() mehr?

Zeus

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.

Gregor

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?

Gregor

-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.

Gregor schrieb:

-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.

Ok, meinst du, es ist sinnvoll, schon von anfang an so seinen Quelltext zu kommentieren, damit man später mit Doxygen eine Doku bauen kann?

Nirvash

-Nachfrage- schrieb:

Ok, meinst du, es ist sinnvoll, schon von anfang an so seinen Quelltext zu kommentieren, damit man später mit Doxygen eine Doku bauen kann?

Dokumentieren von Anfang an ist immer sinnvoll. Tools zur Erstellung einer HTML-Dokumentation wie Doxygen oder JavaDoc bauen zusätzlich noch Konstrukte, welche schnellere Übersichten für Strukturen und Objekte liefern. Solche "Helferlein" schaffen eher bei größeren oder komplexen Projekten einen Mehrwert.

Ja, aber ich muss ja dann in den Kommentaren diese Tokens von Doxygen verwenden.

Ich meinte: Ist es sinnvoll, seinen Quelltext SO (mit Doxygen-Tokens) zu kommentieren?