Lohnt es sich noch C++ zu lernen?

Gregor

RHBaum schrieb:

Nenn mal nen Java Prog, was deiner Meinung nach richtig flott ist, ich schau mirs dann auch mal an ...

Eclipse sollt ich mir eh mal antun ...

Wenn du eh schon weißt, dass du Eclipse testen möchtest, dann tu es doch einfach.

Was hälst du davon: Du zeigst hier ein einfaches C++-Programm, bei dem du denkst, dass eine Java-Variante des Programms weit unterlegen ist und ich programmiere ein entsprechendes Programm in Java. (Aber nur, wenn es nicht allzuviel Code ist, also weniger als 2000 Zeilen in C++.)

DocJunioR

Java war auch nie dazu gedacht, schnell zu sein. Ganz im Gegenteil, man dachte isch, das wird Plattformübergreifend und die Rechner werden eh immer schneller.. Trotzdem war's meiner Meinung nach n klassischer griff ins Klo.
Okay, im Web ist des vielleicht garnicht so dumm, da es eh keinen Web-Compiler gibt..

Hey, wär doch aber mal ne idee, nen html-compiler zu bauen *gg*

RHBaum

@Gregor
Das waere unfair, ich wuerde genau so in C++ schreiben, das dein programm mit Java nie schneller werden kann Ich wuerde was kompliziertes mit der Grafik machen.
Ich denk mal, die Geschwindigkeit von java steht und faellt mit der grafikBiblio. Also wenn was, was ich in C++ entwickle, mit Swing nachbaust, hast nie ne chance .... Und wenn BS spezifische Biblos nimmst ... bist nimmer portabel, die anderen javaianer werden dich auspuhen ....

Bei Vielen Programmen kommt es aber nun mal auf die useability drauf an, zumindest wenn die User den ganzen Tag mit arbeiten. Da sind 1 sec wo du wartest wenn auf nen button druckst und Gar nix passiert (nicht mal ne Rueckmeldung das was passiert) ne ganze menge.
Nen User, der zigtausend Eingabefelder am Tag befuellen muss, und jedes mal ne sekunde oder mehr beim Wechseln mittels Tab warten muss, bis der Focus aufm anderen Feld ist ... wird java verfluchen !

Dagegen fuer einmal am Tag im Internet shoppen langt auch nen java applet

Das begreifen halt die Manager ned ... und scheuen halt fuer die wenigen, die wirklich intensiv mit dem Programm arbeiten, nen userfreundlichen Client zu realisieren ... parallel zu nem client fuer die Gelegenheitsnutzer, die nicht fuer jede Aenderung ne Installationsroutine durchlaufen wollen ....

BTW.
Eclipse ist Lahm ! als Codeeditor wuerd ich es nur ungern nutzen wollen.
Auf meinem Linux rechner sind signifikante Geschwindikeitsunterschiede zu KDevelop ... und das wobei KDE und KDevelop 2.x ned grad als Geschwindikeitsraketen verschrien sind ...

Ciao ...

Gregor

RHBaum schrieb:

@Gregor
Das waere unfair, ich wuerde genau so in C++ schreiben, das dein programm mit Java nie schneller werden kann Ich wuerde was kompliziertes mit der Grafik machen.
Ich denk mal, die Geschwindigkeit von java steht und faellt mit der grafikBiblio. Also wenn was, was ich in C++ entwickle, mit Swing nachbaust, hast nie ne chance .... Und wenn BS spezifische Biblos nimmst ... bist nimmer portabel, die anderen javaianer werden dich auspuhen ....

Red dich nicht raus, Feigling! :p Mach ein Programm, bei dem ich viel Swing brauchen werde und bei dem es deiner Meinung nach mit Java 1 Sekunde dauert, bis auf einen Buttonklick reagiert wird.

...nur eine Bedingung: Lass Bibliotheken von Drittanbietern weg, die man bei Standardprogrammen nicht benötigt. Ich habe keine Lust, mich in soetwas einzuarbeiten. Das beinhaltet Dinge wie OpenGL. Grafikbibliotheken wie Qt, GTK,... kannst du gerne nutzen.

...und: Das Programm muss mindestens unter Win98 oder Linux lauffähig sein, sonst kann ich es nicht testen.

PS: Dir ist offensichtlich klar, dass ich überhaupt nicht verlieren kann. Es ist sicherlich nicht so, dass die anderen Java-Leute mich ausbuhen, wenn mein Programm deutlich langsamer und träger ist, weil es ja nach der hier vorherrschenden Meinung an Java liegen würde. Anders wäre es, wenn dein Programm lahm wäre. Dann hättest du den C++-Leuten ganz schön was zu erklären!

Walli

Du redest grade so, als könntest du jeden Code in Java implementieren, so dass er schneller als C++ ist. Soll ich jetzt lachen weil es so hirnrissig ist oder lachen weil du so rumprollst?

virtuell Realisticer

Schon wieder so ne Diskussion....langsam wirds langweilig

mfg
v R

Gregor

MaSTaH schrieb:

Du redest grade so, als könntest du jeden Code in Java implementieren, so dass er schneller als C++ ist. Soll ich jetzt lachen weil es so hirnrissig ist oder lachen weil du so rumprollst?

Ich sehe es als Experiment an. Eigentlich bin ich selbst gespannt, wieviel schneller ihr ein nicht ganz kleines C++-Programm hinkriegt. Wenn RHBaum nicht will, dann kannst du mir auch gerne ein 1000-2000 Zeilen langes C++-Programm zeigen, von dem du überzeugt bist, dass äquivalentes in Java deutlich unterlegen ist, was die Performance betrifft.

kartoffelsack

Hab keine Lust selber nachzumessen aber ich vertrau Dir und gehe fast jede Wette ein, dass Du das mit Java nicht so schnell hinkriegst wie mit C++

#include <iostream>

int main()
{
  for( int i(0); i < 100000; ++i)
  {
    std::cout << "Das ist der "<<i<<"te Schleifendurchlauf";
  }
}

PS: außerdem ist es unfair, wenn man Bibs von drittanbietern weglassen muss, weil Du genau weißt, dass es keine C++-Standard-GUI-Bib gibt. So kann man dann schwer ein C++-GUI-Prog mit der Java-Swing-GUI vergleichen.

PS: außerdem ist es unfair, wenn man Bibs von drittanbietern weglassen muss, weil Du genau weißt, dass es keine C++-Standard-GUI-Bib gibt. So kann man dann schwer ein C++-GUI-Prog mit der Java-Swing-GUI vergleichen.

Wann wird dieses Manko im Standard endlich ausgemerzt?

Walli

Gregor schrieb:

Wenn RHBaum nicht will, dann kannst du mir auch gerne ein 1000-2000 Zeilen langes C++-Programm zeigen, von dem du überzeugt bist, dass äquivalentes in Java deutlich unterlegen ist, was die Performance betrifft.

Wenn ich die Zeit dazu hätte würde ich den Wettbewerb antreten. Aber 1000-2000 Zeilen nur um zu zeigen das Java langsamer ist bedarf es nicht, da es doch auf der Hand liegt, dass eine Interpretersprache langsamer ist als Maschinencode.

Walli

.. schrieb:

Wann wird dieses Manko im Standard endlich ausgemerzt?

Der Standard kümmert sich nicht um das GUI und von daher ist es kein Manko. Die plattformunabhänige GUI-Erstellung ist imho der einzige Vorteil von Java. Ansonsten kann man auch sehr guten plattformunabhängigen C++-Code schreiben.

kartoffelsack

Solang man weder Netzwerkfunktionalität benötigt oder Threads oder direkt auf ne Tastatureingabe reagieren muss oder ein Verzeichnis durchsuchen will oder ...
Ich muss sagen, dass ich das schon als Manko sehe.

groovemaster

@Gregor
Ich habe auch nicht behauptet, dass es keine Programme gibt, die ausschliesslich in Java programmiert wurden. Allerdings bestärkt mich deine Liste in meinem Glauben. Bis auf den JBuilder und Eclipse sagen mir die anderen Sachen alle nix (aber wer kennt schon jedes Programm ). Und diese beiden sind IDE's in Java für Java. Da werf ich keinen Stein. Oder hast du schon mal Intel für einen AMD Prozessor werben sehen?
Fakt ist aber, dass man mit einer Interpretersprache niemals Programme schreiben kann, die schneller sind, als wenn man sie in einer Compilersprache geschrieben hätte. Wenn dann höchstens gleichschnell, aber selbst dass ist unrealistisch.
Trotzdem will ich Java nicht schlecht machen. Vielleicht gehören ja Interpretersprachen die Zukunft, irgendwann einmal wenn die Rechner so schnell sind, dass Geschwindigkeit für den Heimanwender keine Rolle mehr spielt.

@kartoffelsack
Dass der Standard nichts zu deinen aufgeführten Beispielen sagt, sehe ich ebenfalls als Manko. Trotzdem kann man solche Sachen benutzen und dabei portablen Code schreiben, indem man eigene Klassen dafür einsetzt oder auf frei verfügbare zurückgreift.

Walli

kartoffelsack schrieb:

Solang man weder Netzwerkfunktionalität benötigt oder Threads oder direkt auf ne Tastatureingabe reagieren muss oder ein Verzeichnis durchsuchen will oder ...

Wenn man mal davon absieht, dass Tastatureingaben auch zu einem UI gehören und demnach garnicht zur Debatte stehen sind die Sachen alle plattformabhängig. Ein Taschenrechner kennt kein Netzwerk oder Verzeichnisse...

*aleph_0

Gregor: Ich habe da ein Programm, bei dem ich wirklich überzeugt bin, dass Java schlechter abschneiden würde. Es ist reines Standard-C++, plattformunabhängig und ich habe es erfolgreich unter Linux und Windows kompiliert. Interesse?

Gregor

kartoffelsack schrieb:

Hab keine Lust selber nachzumessen aber ich vertrau Dir und gehe fast jede Wette ein, dass Du das mit Java nicht so schnell hinkriegst wie mit C++
#include <iostream>

int main()
{
  for( int i(0); i < 100000; ++i)
  {
    std::cout << "Das ist der "<<i<<"te Schleifendurchlauf";
  }
}
PS: außerdem ist es unfair, wenn man Bibs von drittanbietern weglassen muss, weil Du genau weißt, dass es keine C++-Standard-GUI-Bib gibt. So kann man dann schwer ein C++-GUI-Prog mit der Java-Swing-GUI vergleichen.

1. Bibliotheken, wie Qt oder GTK habe ich explizit erlaubt. OpenGL ist ein anderes Kaliber.
2.

Otaku@linux:~/TestProjects> cat TestIO.cpp
#include <iostream>

int main()
{
  for( int i(0); i < 100000; ++i)
  {
    std::cout << "Das ist der "<<i<<"te Schleifendurchlauf";
  }
}

Otaku@linux:~/TestProjects> cat TestIO.java
import java.io.*;

public class TestIO
{
   public static void main (String [] args)
   {
      blah();
   }

   public static void blah ()
   {
      PrintWriter out = new PrintWriter (new BufferedOutputStream (System.out));
      for (int i = 0 ; i < 100000 ; ++i)
      {
         out.print ("Das ist der ");
         out.print (i);
         out.print ("te Schleifendurchlauf");
      }
      out.close();
   }
}
Otaku@linux:~/TestProjects> g++ -o TestIO TestIO.cpp -O3
Otaku@linux:~/TestProjects> javac TestIO.java
Otaku@linux:~/TestProjects> time ./TestIO
[...]
real    0m7.306s
user    0m1.900s
sys     0m0.090s
Otaku@linux:~/TestProjects> time java TestIO
[...]
real    0m5.827s
user    0m0.640s
sys     0m0.090s

EDIT: Bevor ich es vergesse:

Otaku@linux:~/TestProjects> g++ --version
g++ (GCC) 3.3 20030226 (prerelease) (SuSE Linux)
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Otaku@linux:~/TestProjects> java -version
java version "1.4.1_02"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06)
Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode)

Gregor

MaSTaH schrieb:

Wenn ich die Zeit dazu hätte würde ich den Wettbewerb antreten. Aber 1000-2000 Zeilen nur um zu zeigen das Java langsamer ist bedarf es nicht, da es doch auf der Hand liegt, dass eine Interpretersprache langsamer ist als Maschinencode.

Wenn du Java immernoch als reine Interpretesprache bezeichnest, dann hast du das Prinzip von Java offensichtlich nicht verstanden.

Gregor

\aleph_0 schrieb:

Gregor: Ich habe da ein Programm, bei dem ich wirklich überzeugt bin, dass Java schlechter abschneiden würde. Es ist reines Standard-C++, plattformunabhängig und ich habe es erfolgreich unter Linux und Windows kompiliert. Interesse?

Ja, wenn es nicht zu sehr aus dem Rahmen 1000-2000 Zeilen fällt.

*aleph_0

Gregor schrieb:

\aleph_0 schrieb:

Gregor: Ich habe da ein Programm, bei dem ich wirklich überzeugt bin, dass Java schlechter abschneiden würde. Es ist reines Standard-C++, plattformunabhängig und ich habe es erfolgreich unter Linux und Windows kompiliert. Interesse?

Ja, wenn es nicht zu sehr aus dem Rahmen 1000-2000 Zeilen fällt.

3000? Es profitiert übrigens sehr von Templates und Operatorenüberladung...

Gregor

\aleph_0 schrieb:

3000? Es profitiert übrigens sehr von Templates und Operatorenüberladung...

Hmmm... in welche Richtung geht es denn? Prinzipiell würde ich das machen, das kann aber ne ganze Zeit dauern, zumal ich demnächst eine Prüfung habe und deshalb momentan nicht soviel Zeit habe.