Warum Java vom Prinzip her schneller als C++?

[Gast]

Auf jeden Fall ist irgendne Mars-Mission schiefgegangen, weil die Entwickler mit einer Mischung aus Zoll und Zentimetern gerechnet hatten. Ich weiß zwar nicht, in welcher Sprache die Software programmiert wurde, aber eine Sprache die sowas erlaubt, gehört in die Sonne geschossen.

[interpreter]

Ich musste mich im Studium 2 Semester mit C++ rumplagen. Umso weiter ich in die Sprache vorgedrungen bin, desto schrecklicher fand ich sie.
Als ich dann Java kennenlernte, war ich bereits recht angetan. Richtig begeistert bin ich jedoch von C#, da es Details, die ich in Java vermisste habe, aufwies. Darunter z.B. Call-By-Reference oder Properties.
Seitdem ich VS.NET 2005 und C# benutze, macht programmieren sogar ein bißchen Spaß.

[Artchi]

ARIANE 5: Die Berechnung der Flugbahn der Ariane 5 wurde in ADA programmiert. Und der Bug war folgender: Es wurde eine 64bit foating Variable in eine 16bit long Variable konvertiert. Der Boardcomputer dachte er wäre auf der falschen Flugbahn und löste eine Exception aus. Da eine falsche Flugbahn aus Sicherheitsgründen eine Exception auslöst, wurde eine Selbstzerstörung einleitet.

Wenn ich es richtig verstanden habe, war die Ariane 5 garnicht auf der falschen Flugbahn, sondern der Boardcomputer hatte halt nur falsche Werte erhalten, durch die konvertierung von 64 auf 16 bit.

Und nein, C++ war nicht im Spiel.

[Gast]

interpreter schrieb:

Ich musste mich im Studium 2 Semester mit C++ rumplagen. Umso weiter ich in die Sprache vorgedrungen bin, desto schrecklicher fand ich sie.
Als ich dann Java kennenlernte, war ich bereits recht angetan. Richtig begeistert bin ich jedoch von C#, da es Details, die ich in Java vermisste habe, aufwies. Darunter z.B. Call-By-Reference oder Properties.
Seitdem ich VS.NET 2005 und C# benutze, macht programmieren sogar ein bißchen Spaß.

Seltsam, ich habe noch nie jemanden sagen hören, dass er bei C# sich gegenüber Java über den Index-Operator freut. Das ist nämlich echt ein Operator, der selbst in Java definierbar sein sollte, denn er ist unär und könnte wie jede Methode dynamisch gebunden werden. Ist der Index-Operator nur mir so wichtig?

[JBeni]

Xin: wenn ich irgendwo nicht antworte, sehe ich deine Argumentation als zutreffend an.

Xin schrieb:

Was die Kleinigkeit angeht: 1.) Java ist noch recht jung, grade mal 13 Jahre alt, man hätte mehr aus C++ lernen können.

Dann wäre es von den C++-Jüngern noch mehr abgelehnt worden. Ausserdem: im Nachhinein findet sich immer etwas, das man noch ändern könnte. Schönes Beispiel sind da die neuen Generics die (endlich) sowas wie Typsicherheit bringen.

In einer Sprache, in der ich nicht verstehen muss, wie der Computer arbeitet, besteht auch keine Notwendigkeit, es den Lernenden beizubringen.

Um ein Java-Progi zu schreiben muss man die Innereien nicht kennen.
Um ein gutes Java-Progi zu schreiben, sollte man durchaus wissen wie ein PC, und noch wichtiger: wie die JVM, funktioniert.

Das Wort "Zeiger" löst bei vielen Angstzustände aus - bei Schülern und Lehrenden, keine Ahnung warum. Also läßt man es in Java weg. Das befreit von Angstzuständen auf beiden Seiten und wenn's keiner laut ausspricht, können wir uns einbilden, dass wie wüßten, was wir tun.

Weil man damit sehr schnell sehr viel verbocken kann. Und herausfinden wer jetzt wieder das Objekt auf das ein Zeiger zeigte gelöscht hatte, gehört zu den eher unangenehmen Tätigkeiten.
Java hat auch "Zeiger" (von einem abstrakten Punkt aus gesehen), nur sorgt der GC dafür und die fehlende Pointerarithmetik für weniger Stolpersteine.

JBeni schrieb:

Man kann auch ein Java-Progi so schreiben, dass es Speicher freigibt, im Gegensatz zu einem wildgewordenen C++-Progi hat es aber keine systemweiten Nebeneffekte.

Welchen Vorteil hat Java, wenn nicht die Standard-Libs. Die GC! Wenn ich die dann auch noch abschaltelte habe....?

Man kann auch Teile auf die Festplatte schreiben, unwichtige Objekte abräumen lassen, den GC muss man dafür nicht gleich ausschalten

Ein Programm, dass mehr Speicher verbraucht als erforderlich, weil die GC noch nicht aufgeräumt hat, halte ich für einen systemweiten Nebeneffekt.
Eine hohe Prozessorlast, weil die GC angesprungen ist, so dass in dem Moment der Computer seine (evtl. getimten oder sogar zeitkritischen) Aufgaben nicht mehr erfüllen kann, halte ich für einen systemweiten Nebeneffekt.

Stattgegeben. Wobei letzteres auch ein Problem des Betriebssystemes ist.

Warum muss ich dann die JVM von Hand erweitern oder beschränken, wenn ich die Resourcen doch habe?

Es ging mir um Eclipse und GoldEd.
Über die seltsam unflexible, problemverursachende, unangepasste Pseudo-Verwaltung von Speicher bei der JVM, möchte ich mich lieber ausschweigen...

Um Details kümmert man sich einmal, wenn man C++ lernt. Dann kennt man die Details und benutzt angemessene Lösungen, die man bei Bedarf anpassen kann und auf das Problem optimieren kann.

Wenn man genügend Aufwand betreibt, kann man nach einigen Jahren auch mit Assembler gut programmieren. Nur bis man es kann, schreibt man blos Quatsch.
Wenn ich Leute beim C++-coden zuschaue habe ich das Gefühl, dass sie die meiste Zeit am optimieren sind, und ansonsten fast nicht vorwärts kommen...

JBeni schrieb:

Die Null-Referenz als Programmierproblem bleibt aber erhalten.

Hättest du lieber automatische Initialisierung? Das würde noch viel mehr Probleme verursachen...

Wie wär's mit der richtigen Informationen an den Entwickeler?

Jetzt bin ich aber gespannt, was soll der Entwickler denn für Informationen bekommen? Vielleicht wäre das aber auch was für einen eigenen Thread

Zu verlangen, dass der Programmierer versteht, was er tut, verkauft sich aber nicht so gut. Java kümmert sich um alles mag vielleicht nicht der Wahrheit entsprechen, klingt in den Ohren derer, die mit Softwarefehlern kämpfen aber besser.

Bitte kein Marketinggeblubber in diesem Thread, wir sind alle genug erfahren, um darauf nicht reinzufallen

Referenzen auf bereits entfernte Objekte gibt es nicht...? Tjo, wir haben uns die Exception auch interessiert angesehen. Die Entwickler mit Besorgnis und ich durfte grinsen. Ich habe die Entwicklung in Java von vorneherein abgelehnt, ergo nicht mein Problem.

Quellcode? Name der Exception? Ansonsten ist das halt doch eine recht dürftige Aussage.

JBeni schrieb:

Mir ist egal, ob ich eine Windows-, eine Linux- oder eine Mac-Version downloade - downloaden muss ich sie so oder so.

Da ich für Leute mit unterschiedlichen Plattformen entwickle, bin ich extrem froh um dieses Feature.
Mein letzter Arbeitsgeber sah das übrigens auch so.

Der Punkt geht erstmal zweifelsohne an Dich, ich habe mich dazu hinreißen lassen, ausschließlich die Portablität aus Anwenderseite zu betrachten. Aus Entwicklerseite ist Java eine schöne Idee.

Danke
Von der Anwenderseite lohnt es sich, wenn man Dualboot hat (Ok, das war jetzt ein schwaches Argument, fast niemand benutzt sowas).

Aber auch hier sehe ich das Problem bisher nur halb. Das Problem ist in der Regel die GUI. Dafür gibt's in C++ auch Libs, ich glaube, da ist Java aber inzwischen mit SWT vorn. Aber die GUI ist auch nur ein kleines Problem - wenn man Software schreibt, die mehr tut als nur eine GUI für eine andere Software anzubieten... Die lagert man entsprechend MVC aus und wenn die vorhandenen Libs nicht gefallen, muss man den Part tatsächlich OS-Konform schreiben. Aber eine GUI stellt doch jetzt nicht ernsthaft eine Herausforderung dar, die in einem nennenswerten Verhältnis zur eigentlichen Software steht?!

Eine gute GUI schreiben ist nicht ganz trivial. Nimm das erstbeste Programm auf deinem PC und guck mal, was dir alles an der GUI nicht gefällt...
Dann benötigt man noch jemanden der die verschiedenen Frameworks gut genug kennt. Und wenn man z.B. Eclipse anschaut: da gibt es doch einige Dialoge und Panels die nicht einfach zu bauen sind (z.B. Syntaxhighlighting).

Wie portabel die verschiedenen (GUI und Nicht-GUI) Libs für C++ sind, kann ich nicht beurteilen, solange man sich auf die STL beschränkt, sehe ich da aber keine grossen Probleme?

Ich selber habe nur die VM für Sun benutzt - bis auf die Linux-Installation, wo Eclipse lief und wegen GNUJava abschmierte.
Wir hatten doch schon ein paar interessante Schritte in Java. 1.1 = 1.2 und alles war anders. 1.4 zu 1.5 war doch auch ein etwas eiliger Schritt.
Frag' mich nicht in Details - ich habe nur den Aufschrei gehört, als 1.5 rauskam und es plötzlich hieß, dass die Techniken von 1.4 nun böse Magie wären.
Dann wurden wohl irgendwelche Kompatiblitätsklassen nachinstalliert, die sind jetzt zwar alle veraltet und sollen in Zukunft bitte nicht mehr verwendet werden, aber wenigstens läuft ältere Software auf 1.5 dann wieder.

1.1 auf 1.2: das war ein grosser Schritt. Das war aber noch in den "Anfangszeiten", da kann man ein paar Änderungen noch verzeihen (bei .NET ist ja 1 und 2 auch nicht 100% kompatibel).
1.4 auf 1.5: Auch da kam viel Neues hinzu (sogar syntaxmässig), und Altes wurde als "veraltet" deklariert.
Dass alte Software nicht mehr funktioniert, höre ich allerdings zu ersten mal.

JBeni schrieb:

In Embedded Systems wird Java dann auf C++ kaputtgebrochen (Garbagecollection aus, Speicher anfordern und brav von Hand wieder freigeben).

Entweder alles oder nichts. Von solchen Dingen halte ich auch nicht viel. Wenn man den GC nicht nutzen will, soll man auch kein Java verwenden.

Ich zitiere Dich (s.o.) "Man kann auch ein Java-Progi so schreiben, dass es Speicher freigibt, ...". Wo es eben noch als Argument für Java galt, so sollte man es(Java/das Arguemnt) doch nicht nutzen, wenn's drauf ankommt!?

Siehe ebenfalls oben "Mit weniger drastischen Mitteln".
Wenn man sich auf Eigenheiten eines Systemes nicht einlassen will, sollte man lieber ein anderes nehmen, bevor man gefährlich tief im System Dinge abändert. Die Chancen, dass einem so ein verändertes System um die Ohren fliegt, würde ich als nicht allzu gering einschätzen.
Wie gesagt: Java ist auch kein Allheilmittel.

Ich portiere die Algorithmen 1:1 in optimiertes C um. Eine nachträgliche Optimierung findet nicht mehr statt. Ich programmiere grundsätzlich optimiert, ich kenne die meisten Fallgruben und umgehe sie entsprechend. Bei der 1:1 Portierung verstehe ich den Algorithmus und seine Besonderheiten. Anschließend reiche ich - wenn mir passendes einfällt - eine Empfehlung ein, wie man den vorhandenen Algorithmus ersetzen könnte, gegen einen anderen, der aber identische Ergebnisse liefert. Wurde bisher noch nie umgesetzt, die 1:1 Portierungen waren bereits wesentlich schneller, als benötigt.

Da ich diese Algorithmen und den Quellcode nicht kenne (und auf die schnelle wohl auch nicht verstehen würde), gebe ich dazu keinen Kommentar ab.

Ich habe Java-Kenntnisse. Nachdem ich sie mir vor 3 oder 4 Jahren angeeignet habe, fand ich Vorzüge gegenüber C++, aber ich fand mehr, was ich C++ bevorzuge. Mir gefiel Java nicht. Trotzdem habe ich ein Projekt damit gemacht, denn wenn alle Java so toll finden und ich nicht, bin ich vermutlich der Depp und muss mal was richtiges mit Java schreiben. Mit dem Projekt wollte ich Erfahrung sammeln. Das habe ich.

Mir gefällt Eiffel nicht, obwohl alle Welt voll davon überzeugt zu sein scheint. Ok, ich verstehe was du meinst.

Seitdem habe ich kein Java mehr programmiert und meine Kenntnisse auch nicht mehr auf den aktuellen Stand gebracht.
Seit 1.5 wollte ich mich mal wieder auf den aktuellen Stand bringen, mir die generics usw mal ansehen, aber bisher fehlte die Zeit und die Notwendigkeit. Wo Java und C# in ihren aktuellen Versionen nun generics eingefügt haben, bemerke ich, dass generische Programmierung gute Chancen auf den nächsten Hype hat.
Generische Programmierung kennt C++ seit 1990, afair.

Also die Kleinkinder-Generics von C# wollen wir mal nicht mit C++ oder Java vergleichen
Die Generics von Java sind anders als die C++-Templates. Die beiden Dinge haben zwar manchmal ähnliche Effekte, sehen syntaxmässig auch ziemlich ähnlich aus, im Detail finde ich sie aber schlecht vergleichbar. Schau es dir am besten selbst mal an...
Zum Hype: eindeutig. Die Generics hätten seit Java 1.0 in der Sprache sein sollen, aber man wollte die Sprache ja einfach halten. Manchmal wars leider zu einfach.

Inzwischen bin ich da vorsichtiger geworden. Abstraktion ist für große Projekte unverzichtbar, aber man sollte den Kontakt zum Grund nicht verlieren.

Jop. Aber man muss sich ja auch nicht an ihm festketten

Wenn's dann darum geht Lösungen zu produzieren, lande ich häufig wieder bei C++ bzw. C#. Beide Sprachen erlauben ein hohes Maß an Abstraktion, C++ steht aber mit allen Bits auf'm Grund und bei C# gibt's zumindest eine Lucke mit "unsafe", wenn man doch mal an die Basis muss.
Kann auch daran liegen, dass ich bisher selten Probleme lösen musste, die sich von einer abstrakten Basisklasse ableiten lassen.

Übungssache. Wenn ich ein komplexes Problem lösen will, lande ich meist bei Java. Da kann ich genügend Abstraktion einführen um das Problem in Einzelteile zu zerlegen.

Und ich arbeite seit 2003 dran. Ich schreibe mir Konzeptfehler auf und Konzepte, die ich beim Programmieren in diversen Sprachen vermisse, entwickle sie und probiere sie in meinem Compiler aus. Teste, wie sich vorhandene Konzepte abstrahieren lassen, wie sich neue Konzepte in die Sprache einfügen, wie sie sich anfühlen, ob sie intuitiv verständlich sind. Ich habe 2003 bei C++ angefangen, wollte zuerst eine kompatible Erweiterung zu C++ und habe dabei erkannt, dass sich die C++ Syntax so nicht halten läßt, wenn man Konzeptfehler korrigieren möchte.

Interessant. Gibts darüber mehr zu lesen? Ich bastle mir gerade eine Scriptsprache zusammen und gucke jede Idee gerne an.

Bjarne Stroustrup hat viele Entscheidungen, aber auch Fehler in C++ in seinem Buch 'Design und Entwicklung von C++' beschrieben. Bei Java weiß ich nicht, ob Stroustrup seine Erfahrungen da schon so offen berichtet hat.

Hab nichts gehört, hab aber auch nicht aktiv danach gesucht. Kritiken von Java gibt es aber genügend (leider in 99% aller Fälle von Möchtegernexperten )

Meine Programmiersprachensuppe besteht aus verschiedenen Basic-Dialekten, Assembler auf verschiedenen Prozessoren, C#, (Objective) Pascal, JavaScript, Prolog, PHP, SQL.
Dazu kommt ein klein wenig Lisp, was Perl, Rebol, Python und Rexx oder ein Hauch Fortran und andere heutzutage eher exotische Sprachen. Ich habe '86 angefangen zu programmieren und schaue mich regelmäßig um. Ruby soll auch nicht verkehrt sein.
Bisher sehe ich allerdings leider(!) keine bedeutende Alternative zu C++. Java hat's versucht, Java hatte Chancen, aber in meinen Augen reicht es nicht.

Haskell kann ich dir noch empfehlen. Wie Prolog, nur besser. Ich vermisse da nur einige Libraries, aber wenig Benutzer -> wenig Libraries -> wenig Benutzer ...
Man benötigt irgendeine hardwarenahe Sprache (wie soll man sonst z.B. Treiber schreiben?). C++ wird nur schon deswegen nicht so schnell aussterben.
Wenn es um normale Desktopanwendungen geht, bleibt Java für mich erste Wahl. Die Libraries sind gut, die Entwicklung schnell, die Fehlermeldungen aussagekräftig und die Geschwindigkeit zur Laufzeit hoch. Bei Pt. 2 und 3 hält C++ nicht immer mit.
Für Anwendungen die in irgendwelchen Grenzbereichen arbeiten, gibt es keine allgemeingültige Aussagen.

[Cyriz]

Java hin, Java her...

Ich finde wer ernsthaft Programmieren will (und dazu gehören auch die Kenntnisse über die Hardware, und wie bestimmte Sachen im Rechner nunmal vorsich gehen) sollte erst C++ (C) lernen und dann umsteigen (oder bei bleiben). Auserdem ist der Weg von C auf Java leichter, als andersrum.
Meine Meinung, nix gegen die Java-Jungs.

Und in Sachen Effizienz stellt C++, Java in den Schatten.
http://verify.stanford.edu/uli/java_cpp.html

grüße

P.S. Java ist wie automatik fahren

[Walli]

Cyriz schrieb:

Und in Sachen Effizienz stellt C++, Java in den Schatten.
http://verify.stanford.edu/uli/java_cpp.html

Mal ganz davon abgesehen, dass der Test alleine nicht unbedingt so toll ist um die Performance von Java und C++ zu vergleichen hat die JVM sich in den letzten Jahren weiterentwickelt.

Aber ich mag Java trotzdem nicht .

[Xin]

JBeni schrieb:

Xin: wenn ich irgendwo nicht antworte, sehe ich deine Argumentation als zutreffend an.

Klingt sinnig, der Thread ist eh lang genug.

JBeni schrieb:

Xin schrieb:

Was die Kleinigkeit angeht: 1.) Java ist noch recht jung, grade mal 13 Jahre alt, man hätte mehr aus C++ lernen können.

Dann wäre es von den C++-Jüngern noch mehr abgelehnt worden. Ausserdem: im Nachhinein findet sich immer etwas, das man noch ändern könnte. Schönes Beispiel sind da die neuen Generics die (endlich) sowas wie Typsicherheit bringen.

Warum sollte man eine Sprache ablehnen, nur weil sie nicht wie C/C++ ist?
C/C++/C#/Java/PHP/undsoweiter haben Konzepte, die sich bewährt haben. Kein Grund, die zu verändern.
Aber da sind auch Schreibweisen drin, denen eine Änderung gut zu Gesicht stehen würde. Der Zuweisungsoperator im Verlauf der Geschichte ist mit Basic frontal gegen die Wand gefahren worden, trotzdem ist bei B/BCPL/C offenbar keiner auf die Idee gekommen, daran mal'n Gedanken zu verschwenden.

JBeni schrieb:

Um ein Java-Progi zu schreiben muss man die Innereien nicht kennen.
Um ein gutes Java-Progi zu schreiben, sollte man durchaus wissen wie ein PC, und noch wichtiger: wie die JVM, funktioniert.

Jow, hier sind wir uns einig. Um das nochmal zusammen zufassen, gute Programme kommen von gut ausgebildeten und erfahrenen Programmieren - unabhängig von der verwendeten Sprache.

JBeni schrieb:

Das Wort "Zeiger" löst bei vielen Angstzustände aus - bei Schülern und Lehrenden, keine Ahnung warum. Also läßt man es in Java weg. Das befreit von Angstzuständen auf beiden Seiten und wenn's keiner laut ausspricht, können wir uns einbilden, dass wie wüßten, was wir tun.

Weil man damit sehr schnell sehr viel verbocken kann. Und herausfinden wer jetzt wieder das Objekt auf das ein Zeiger zeigte gelöscht hatte, gehört zu den eher unangenehmen Tätigkeiten.
Java hat auch "Zeiger" (von einem abstrakten Punkt aus gesehen), nur sorgt der GC dafür und die fehlende Pointerarithmetik für weniger Stolpersteine.

Ein gut und sauber aufgebautes C++ Programm hat wenige delete Befehle, die dafür an den richtigen Stellen.
Irgendjemand hat hier ein witziges Zitat von Stroustrup in der Sig - finde ich sehr passend.

Ich habe mir sehr lange sehr viele Gedanken über die Notwendigkeit einer GC Gedanken gemacht, da ich die Vorteile sehe.
Ich sehe aber auch, warum die Vorteile überhaupt als Vorteile erkannt werden: Man verhindert, dass der Programmierer Fehler macht, in dem man den Computer die Speicherfreigabe durchführen lässt. Das erkauft man sich mit einer VM, die alles andere als wenig Aufwand bedeutet.
Vielleicht kann man sich aber auch mal Gedanken über Hilfskonstrukte machen, die keiner VM bedürfen.

JBeni schrieb:

JBeni schrieb:

Man kann auch ein Java-Progi so schreiben, dass es Speicher freigibt, im Gegensatz zu einem wildgewordenen C++-Progi hat es aber keine systemweiten Nebeneffekte.

Welchen Vorteil hat Java, wenn nicht die Standard-Libs. Die GC! Wenn ich die dann auch noch abschaltelte habe....?

Man kann auch Teile auf die Festplatte schreiben, unwichtige Objekte abräumen lassen, den GC muss man dafür nicht gleich ausschalten

Swappen kostet Zeit und nicht alle Systeme besitzen eine Harddisk oder vergleichbares.

JBeni schrieb:

Ein Programm, dass mehr Speicher verbraucht als erforderlich, weil die GC noch nicht aufgeräumt hat, halte ich für einen systemweiten Nebeneffekt.
Eine hohe Prozessorlast, weil die GC angesprungen ist, so dass in dem Moment der Computer seine (evtl. getimten oder sogar zeitkritischen) Aufgaben nicht mehr erfüllen kann, halte ich für einen systemweiten Nebeneffekt.

Stattgegeben. Wobei letzteres auch ein Problem des Betriebssystemes ist.

Ein Programm, dass auf einmal und ohne brauchbare Kontrolle des Benutzers große Mengen Rechenleistung anfordert, kann nicht Problem des Betriebsystems sein.
Auch das Java-Programm kann für zeitkritische Anwendungen verantwortlich sein (da wären wir wieder: "Programmierer werden schneller dumm, als Computer schnell werden").
Einer wird den Kürzeren ziehen, weil die Rechenzeit nunmal erst unter kontrolle zu bekommen ist, wenn eine Zusatz-Hardware die Zusatzaufgaben erledigt, die Java vom
Computer verlangt.

JBeni schrieb:

Über die seltsam unflexible, problemverursachende, unangepasste Pseudo-Verwaltung von Speicher bei der JVM, möchte ich mich lieber ausschweigen...

Warum? Reden ist Silber, Schweigen ist Gold?

Pseudoverwaltung von Speicher ist ein interessantes Stichwort. Ein kleines Programm benötigt nur wenig Speicher. Wenn ich es in C++ schreibe, forder ich den Speicher an und gebe keinen Speicher mehr frei. Beende ich das Programm, entfernt ein modernes OS sämtliche Resourcen, was dem Verhalten von Programmen in GC-Sprachen nicht selten entspricht. Wenn man eine GC hat, ist das modern, macht man das mit C++ ist das falsch. Über Speichermangel klagen beide, wenn man es übertreibt.

Bei einer nicht geringen Zahl von Programmen würden die temporären Speicherlecks nichtmals den Speicherverbrauch der JVM erreichen, würden also unterm Strich trotz Speicherverschwendung speichersparender arbeiten als das entsprechende fehlerfreie Java-Programm. Hat der Admin -Xms defaultmäßig gleich mit ausreichend RAM ausgestattet, läßt sich das Szenario noch viel schöner aufziehen.

JBeni schrieb:

Wenn man genügend Aufwand betreibt, kann man nach einigen Jahren auch mit Assembler gut programmieren. Nur bis man es kann, schreibt man blos Quatsch.
Wenn ich Leute beim C++-coden zuschaue habe ich das Gefühl, dass sie die meiste Zeit am optimieren sind, und ansonsten fast nicht vorwärts kommen...

Hier kommt wohl noch etwas ins Spiel: Die Frage, ob man eine optimierte und feingetunte Software wünscht, oder nur eine Software, die funktioniert.
Erstere Gruppe wird vermutlich eher C/C++ nehmen, zweitere wird sich ausgibig an den Standardlibs von Java und .NET bedienen.

Ich las eben, dass die VM mit VC6 kompiliert würde. Ob das stimmt - who knows. Aber warum wird Java eigentlich nicht in Java entwickelt?

JBeni schrieb:

Referenzen auf bereits entfernte Objekte gibt es nicht...? Tjo, wir haben uns die Exception auch interessiert angesehen. Die Entwickler mit Besorgnis und ich durfte grinsen. Ich habe die Entwicklung in Java von vorneherein abgelehnt, ergo nicht mein Problem.

Quellcode? Name der Exception? Ansonsten ist das halt doch eine recht dürftige Aussage.

Hehehe, ich gehe davon aus, dass ich vorher bereits deutlich genug zu verstehen gegeben habe, dass ich kein Java mehr progammiere - es stand ja wörtwörtlich da. Das war nicht mein Projekt, nicht mein Problem, ich habe keine Screenshots oder Dokumentation dazu aufgehoben. Es ist mir allerdings auch mal in JavaScript passiert - ich weiß MSIE-JavaScript != SunVM, aber für mich bedeutet das, dass die Entwicklung eines fehlerfreien GC scheinbar ein Problem für sich ist, auf das ich als Entwickler keinen Einfluss habe.
Ich vermeide die Benutzung von Software, auf die ich keinen Einfluss habe.

JBeni schrieb:

Von der Anwenderseite lohnt es sich, wenn man Dualboot hat (Ok, das war jetzt ein schwaches Argument, fast niemand benutzt sowas).

95% der Linux-Anwender? Ich habe auch noch eine Windows-Version, wenn auch fast nur zum Spielen, wenn ich mal dazu komme.

JBeni schrieb:

Eine gute GUI schreiben ist nicht ganz trivial. Nimm das erstbeste Programm auf deinem PC und guck mal, was dir alles an der GUI nicht gefällt...
Dann benötigt man noch jemanden der die verschiedenen Frameworks gut genug kennt.

Stimmt. Aber wo ist das Problem - weigern sich Programmierer bzgl. GUI-Frameworks dazuzulernen?

JBeni schrieb:

Und wenn man z.B. Eclipse anschaut: da gibt es doch einige Dialoge und Panels die nicht einfach zu bauen sind (z.B. Syntaxhighlighting).

Was das Syntax-Highlighting angeht, darf ich mitrden: dynamisches Syntax-Highlighting (also zur Laufzeit modifizierbar, inkl. Parser, der die Syntaxbeschreibung liest und für den Editor übersetzt) zu entwickeln dauerte 4 Stunden (C++). Ich war selbst etwas überrascht.

JBeni schrieb:

1.1 auf 1.2: das war ein grosser Schritt. Das war aber noch in den "Anfangszeiten", da kann man ein paar Änderungen noch verzeihen (bei .NET ist ja 1 und 2 auch nicht 100% kompatibel).
1.4 auf 1.5: Auch da kam viel Neues hinzu (sogar syntaxmässig), und Altes wurde als "veraltet" deklariert.
Dass alte Software nicht mehr funktioniert, höre ich allerdings zu ersten mal.

C++ achtet sehr auf Kompatiblität zu Vorgängerversionen. Es reicht trotzdem nicht. Ich hatte letztes Jahr eine nette Diskussion mit jemanden, der Probleme hat C-Sourcecode von anno dazumal auf aktuellen C++ Compilern zu kompilieren. Neuentwickeln ist zu teuer. Diese Leute interessiert "Das war ein großer Schritt" nicht. Die haben Software, die ein aktueller Compiler mit abertausenden Warnings kompiliert. Ob das alles wirklich noch funktioniert? Alles nochmal anfassen? Wer weiß, was dann alles versehentlich verändert wird!?

Wenn ich dem was von Java erzählen würde, der würde mich fragen, warum er nicht gleich PHP nehmen soll.

JBeni schrieb:

Inzwischen bin ich da vorsichtiger geworden. Abstraktion ist für große Projekte unverzichtbar, aber man sollte den Kontakt zum Grund nicht verlieren.

Jop. Aber man muss sich ja auch nicht an ihm festketten

Hehehe... das ist genau die Argumentation, die ich so schätze. C++ ist nicht am Boden angekettet: Templates in C++: 1990, da hieß Java noch Oak... nein, Oak kam, glaub ich '92... C++ konnte schon fliegen, da gab's Java noch nicht. Früher hatte Java nur klasse Autos, da war C++ ja nur ein C mit "class". Jetzt dürfen Java typsicher durch generics und schon fliegt die Java-Gemeinde auf generische Programmierung und C++-Programmierer sind am Prozessorboden festgekettet.
Willst Du den Hype der nächsten Generation wissen? Zu Fuss gehen. Mal gucken, ob das in der nächsten Version von Java auch drin ist - C# hat es ja über das unsafe-Schlüsselwort integriert.
Java 1.6 hat GARANTIERT ein Schlüsselwort, um Klassen zu verschachteln und alle werden jubeln und sagen 'Java ist die inovativste Sprache der Welt' und diejenigen, die C++ programmieren, werden wieder mal freundlich lächeln und sich einen grinsen.

In C++ habe ich seit 15 Jahren freie Wahl des Verkehrsmittels. Deswegen bekomme ich dann zu hören, da macht ja jeder alles, wie er will - den Sourcecode versteht dann ja kein Mensch mehr. Wart mal ab: In fünf Jahren wird die Java-Gemeinde die freie Wahl des Verkehrsmittels feiern und auch noch glauben, was ultimativ Neues gefunden zu haben.

JBeni schrieb:

Und ich arbeite seit 2003 dran. Ich schreibe mir Konzeptfehler auf und Konzepte, die ich beim Programmieren in diversen Sprachen vermisse, entwickle sie und probiere sie in meinem Compiler aus. Teste, wie sich vorhandene Konzepte abstrahieren lassen, wie sich neue Konzepte in die Sprache einfügen, wie sie sich anfühlen, ob sie intuitiv verständlich sind. Ich habe 2003 bei C++ angefangen, wollte zuerst eine kompatible Erweiterung zu C++ und habe dabei erkannt, dass sich die C++ Syntax so nicht halten läßt, wenn man Konzeptfehler korrigieren möchte.

Interessant. Gibts darüber mehr zu lesen? Ich bastle mir gerade eine Scriptsprache zusammen und gucke jede Idee gerne an.

Zu lesen gibt's darüber nicht wirklich was, weil ich die eigentlichen Ideen nicht veröffentliche, sondern nur auf meinem Rechner ausprobiere und brauchbare Ideen halt im Compiler lasse. Ich werde sie veröffentlichen, wenn ich mit der Sprache zufrieden bin und der Compiler fertig ist. Wenn Du Dich mit mir bzgl. Sprachentwicklung austauschen willst, schreib' mir eine PM. Das Compilerprojekt packe ich aber erst detailiert aus, wenn er meinen Erwartungen gerecht wird.

JBeni schrieb:

Bjarne Stroustrup hat viele Entscheidungen, aber auch Fehler in C++ in seinem Buch 'Design und Entwicklung von C++' beschrieben. Bei Java weiß ich nicht, ob Stroustrup seine Erfahrungen da schon so offen berichtet hat.

Hab nichts gehört, hab aber auch nicht aktiv danach gesucht. Kritiken von Java gibt es aber genügend (leider in 99% aller Fälle von Möchtegernexperten )

Ich habe an Java nix zu kritisieren. Java existiert, so wie es ist, es hat seine Felder in denen es sich bewährt und ich arbeite in diesen Feldern nicht.
Ich kritisiere diejenigen in der Java-Gemeinde, die glauben, dass Java die Antwort auf alle Fragen ist. Ich kritisiere diejenigen, die ohne wirkliche C++-Kenntnisse glauben, über C++ urteilen zu können. Und ganz besonders kritisiere ich, dass behauptet wird, dass Zeiger Probleme verursachen. Schlecht ausgebildete Programmierer verursachen Probleme.
Mit Zeigern zu programmieren ist Kampfjet-Fliegen. Dass Programmierer aus der Sandbox da abstürzen, ist in der Regel keine Fehlfunktion des Jets.

Hübsches Zitat... wenn's nicht arrogant wäre, sich selbst zu zitieren, hätte es Chancen, in meine Sig zu kommen

JBeni schrieb:

Haskell kann ich dir noch empfehlen. Wie Prolog, nur besser.

Kennst Du ein gutes Tutorial, ich wäre interessiert, da Du nicht der erste bist, der mich auf Haskell aufmerksam macht.

JBeni schrieb:

Man benötigt irgendeine hardwarenahe Sprache (wie soll man sonst z.B. Treiber schreiben?). C++ wird nur schon deswegen nicht so schnell aussterben.

Informatiker werden immernoch gesucht.
Trotzdem finden viele Informatiker keine Arbeit.

Vielen fehlt es an Visionen. Das können Vorgesetzte kompensieren.
Den meisten fehlt das Verständnis, was sie da wirklich tun. Solche Leute programmieren auch C++ und man kann es ihnen leider nicht verbieten. Solche Leute mache ich verantwortlich für den inzwischen schlechten Ruf unter Nicht-C++-Programmieren.
Meine Software ist auch nicht immer fehlerfrei und ich musste Fehler in meiner Software korrigieren. Kein Fehler wurde durch falsch verwendete Zeiger verursacht.

[SIDEX]

hallölchen

nun wollt ich mich hier mal auch bisschen abreagieren *g*
natürlich kann ich nicht viel mit manchen leuten mithalten die schon jahrelang erfahrung haben aber trotzdem will ich mal was sagen.

also ich bin informatik stundent an der uni bremen im ersten semester und werde momentan gezwungen java zu lernen *g* auch in diesem augenblick liegt "java ist auch eine insel" aufgeschlagen vor mir. (nebenbei erwehnt, das mit der adreane 5 wird hier auch als beispiel genannt *g*)
habe 3 jahre delphi hiter mir und danach hab ich angefangen c++ zu lernen bevor ich erfahren habe dass man dies erst im 3 semester braucht.
also ich muss sagen als ich erste schritte in java gemacht habe, konnte ich schon von der sprache fast kotzen. die schönen sprüche dass java c++ sehr ähnlich sei haben mir am anfang hoffnung gemacht aber jetzt würde ich jeden umbringen der das noch mal behauptet.
ohne genau zu werden muss ich als erstes sagen unter c++ hatte ich einfach das gefühl mehr kontrolle über meinen rechner zu haben.

natürlich muss ich auch sagen, dass diese diskussion darüber welche sprache nun besser ist eh in die leere führt. in der welt hat alles seine vor und nachteile, von einer waschmaschiene bis zu den programmiersprachen. und ein guter programmieren, solange es ihm nicht vorgeschrieben wird, kann beides und setzt beides auch richtig ein.

zu sagen dass java so wundervoll ist weil es nun so schön platformunabhängig ist find ich unsiinig. ist denn c++ nicht platformunabhängig? ok dann muss ich eben paar zeilen code ändern und neu compilieren, und? java im vergleich zu c# ist aber wiederum besser, weil nun wirklich platformübergreifend ist. c# kann das nur, tut es aber nicht wirklich.
jemand meinte hier dass c# besser sei weil es call by reference untertzützt? das ist quatsch mit souce sag ich nur!!! java unterstützt das zwar nicht direkt aber man kann es umgehen in dem man einfach eine klasse dafür macht und das dann als paramter nutzt. Wieso? weil (und nun kom ich zu einem für mich sehr sehr verwirrenden teil in java)

man kann java nähmlich sehr einfach in einem satz beschreiben:
beinahe jedes element seien es strings, arrays und und und, ist ein objekt, weil sie von der java.lang.object abstammen und erben und jedes objekt ist wiederum eine referenz.

so und nun sagt sun java ist sicherer, weil sie auf die zeiger verzichtet haben? LOOOOL *g* hier ist einfach alles eine referenz. echt respekt jungs, da haben die echt mal was geschafft. und die nullpointerexception nervt einen überhaupt nicht jede 5 sekunden.

soooooo, weiter gehts. kommen wir zu GC von java. okay ist n schönes teil, weil man nicht für jeden mist einen destruktor schreiben muss aber, dass eine maschiene es besser machen kann als der mensch, glaub ich einfach nicht. ausserdem tuen manche so als ob es keinen für c++ gäbe. hab zwar noch nie einen benutzt aber gehört habe ich schon mal davon, zumindest, dass es in entwicklung ist.

ok noch ein nachteil von java: schon mal gesehen wie ein array von der JVM implementiert wird? nein? okay ein beispiel:

int[] lahmarsch = { 1, 2, 3 };

//und so siehts dann aus

int[] lahmarsch = new int[3];
lahmarsch[0] = 1;
lahmarsch[1] = 2;
lahmarsch[2] = 3;

juhu und jetzt stellt euch mal nen mille-array vor. ich weiß zwar nicht genau aber ich vermute mal in c++ wird es anders behandelt. so und java soll schneller sein? wieder mal quatsch mit souce

so ich glaube ich sollte zum ende kommen ansonsten kann ich mich hier noch die ganze nacht über java beschwerren.

mein fazit ist: das einzige was mir in java gefällt, wirklich das einzige!, ist die typanpassung und ansonsten könnte ich von dieser sprache nur kotzen.
okay ich bin dann mal weiter java lernen, habe bald fachgespräche

ahhh noch was vergessen. ich habe schon oft gesehen dass die java-fans sich über zeiger-auf-zeiger in c++ beschwerrt haben weil es so verwirrend war. dazu muss ich ne frage stellen: ist java denn so perfekt und nichts verwirrendes beinhaltet, nur weil es dort keine zeiger und mehrfachvererbung gibt? java kann z.B: mit den ganzen klammern nur so vor sich hin spucken, da soll mal einer klar kommen.

[Gast]

SIDEX schrieb:

ok noch ein nachteil von java: schon mal gesehen wie ein array von der JVM implementiert wird? nein? okay ein beispiel:

int[] lahmarsch = { 1, 2, 3 };

//und so siehts dann aus

int[] lahmarsch = new int[3];
lahmarsch[0] = 1;
lahmarsch[1] = 2;
lahmarsch[2] = 3;

juhu und jetzt stellt euch mal nen mille-array vor. ich weiß zwar nicht genau aber ich vermute mal in c++ wird es anders behandelt. so und java soll schneller sein? wieder mal quatsch mit souce

Häh? Gib mir auch mal was von deinen Drogen.

[SIDEX]

bitte schön:

http://www.galileocomputing.de/openbook/javainsel/java-03.htm#Xxx279093

aber krieg keine überdosis

[JBeni]

Warum sollte man eine Sprache ablehnen, nur weil sie nicht wie C/C++ ist?

Das frag nicht mich! Ich kenne jedenfalls mehr als einen Programmierer die bei allem was kein "C" im Namen hat rot sieht (und das sind keine Anfänger). Woher das kommt... wüsste ich auch gerne.

Ein Programm, dass auf einmal und ohne brauchbare Kontrolle des Benutzers große Mengen Rechenleistung anfordert, kann nicht Problem des Betriebsystems sein.

Ok, hier sollte man differenzieren: wenn mehrere Programme laufen und eines klaut den anderen Rechenzeit, dann ist das OS schlecht (*hüstel* kann man immerwieder schön bei Windows beobachten...).
Wenn es programmintern abläuft, ists natürlich was anderes.

Auch das Java-Programm kann für zeitkritische Anwendungen verantwortlich sein.

Hm, mal ein bisschen rumgegoogelt. Da gibt es doch das ein oder andere Projekt das sich genau mit diesem Problem befasst. Wieweit die Page Marketingeblubber ist, und wieviel davon echt ist, weiss ich aber nicht.

JBeni schrieb:

Über die seltsam unflexible, problemverursachende, unangepasste Pseudo-Verwaltung von Speicher bei der JVM, möchte ich mich lieber ausschweigen...

Warum? Reden ist Silber, Schweigen ist Gold?

Das System ist IMHO der grösste Nachteil der JVM, deshalb schweige ich.

Bei einer nicht geringen Zahl von Programmen würden die temporären Speicherlecks nichtmals den Speicherverbrauch der JVM erreichen, würden also unterm Strich trotz Speicherverschwendung speichersparender arbeiten als das entsprechende fehlerfreie Java-Programm.

Naja, das OS ist auch so eine Art VM. Von daher benötigen heutige Programme von Grund auf ~300 MB RAM

JBeni schrieb:

Von der Anwenderseite lohnt es sich, wenn man Dualboot hat (Ok, das war jetzt ein schwaches Argument, fast niemand benutzt sowas).

95% der Linux-Anwender? Ich habe auch noch eine Windows-Version, wenn auch fast nur zum Spielen, wenn ich mal dazu komme.

95% * (10% Systeme die überhaupt Linux haben) * (10% Die dieselbe Software auf beiden Systemen benötigen) = verschwindend gering

JBeni schrieb:

Dann benötigt man noch jemanden der die verschiedenen Frameworks gut genug kennt.

Stimmt. Aber wo ist das Problem - weigern sich Programmierer bzgl. GUI-Frameworks dazuzulernen?

Hoffentlich nicht *g*. Aber man kann ein Framework nicht in einem Tag kennen lernen. Wenn dann Wochen auf kennen lernen + coden + debuggen + etc. draufgeht ist das nicht so dolle.

C++ achtet sehr auf Kompatiblität zu Vorgängerversionen. Es reicht trotzdem nicht. Ich hatte letztes Jahr eine nette Diskussion mit jemanden, der Probleme hat C-Sourcecode von anno dazumal auf aktuellen C++ Compilern zu kompilieren. Neuentwickeln ist zu teuer. Diese Leute interessiert "Das war ein großer Schritt" nicht. Die haben Software, die ein aktueller Compiler mit abertausenden Warnings kompiliert. Ob das alles wirklich noch funktioniert? Alles nochmal anfassen? Wer weiß, was dann alles versehentlich verändert wird!?

Wenn ich dem was von Java erzählen würde, der würde mich fragen, warum er nicht gleich PHP nehmen soll.

Mein Kollege hat sich letzhin ein neues Visual Studio besorgt. Er fluchte gottsjämerlich, dass nichtmal der Code geschrieben im Vorgänger kompilierte...

Als ich von 1.4 auf 1.5 wechselte gabs ein paar Warnungen, aber die Programme liefen dennoch ohne Probleme. Mit ein paar Klicks in der IDE waren auch die Warnungen hübsch sortiert, und die 1.4<->1.5 Warnungen konnten ignoriert werden (der Code war ja nach 1.4-Standard korrekt).

Ich konnte also mitten in der Projektentwicklung die Version wechseln. Sorry, bis heute konnte mir noch niemand ein Versionsproblem bei Java (inkl. Quellcode!) zeigen (nicht mal der TGGC ), hier ist ein + Punkt für Java.

Willst Du den Hype der nächsten Generation wissen? Zu Fuss gehen. Mal gucken, ob das in der nächsten Version von Java auch drin ist - C# hat es ja über das unsafe-Schlüsselwort integriert.

Und dann C++-Code direkt in Java eingebettet? Mal bitte den Teufel nicht an die Wand
Und nein, das ist sehr unwahrscheinlich, eigentlich wird versucht Java "rein" zu halten. Java springt nicht auf jeden Featureitis-Hype-Zug auf, sondern versucht sich solange wie möglich vor Innovationen zu schützen. Deshalb dauerte es auch so elend lange bis endlich Generics kamen.

Java 1.6 hat GARANTIERT ein Schlüsselwort, um Klassen zu verschachteln und alle werden jubeln und sagen 'Java ist die inovativste Sprache der Welt' und diejenigen, die C++ programmieren, werden wieder mal freundlich lächeln und sich einen grinsen.

Hr, braucht es nicht. Gibt es schon seit Java 1.2 (oder wars 1.1?). Das nennt sich innere, anonyme oder Methodenklasse (Klassen kann man direkt in einer Methode definieren. War ziemlich überrascht, als ich das bemerkte).
Java 1.6 wird (wie immer) Erweiterungen der Standardlib haben, der Syntax wird nicht verändert.

In C++ habe ich seit 15 Jahren freie Wahl des Verkehrsmittels. Deswegen bekomme ich dann zu hören, da macht ja jeder alles, wie er will - den Sourcecode versteht dann ja kein Mensch mehr.

Du willst sagen, du verstehst den Quellcode eines fremden C++-Programmieres beim ersten hinschauen? Hut ab, aber dafür hast du lange geübt.

Wart mal ab: In fünf Jahren wird die Java-Gemeinde die freie Wahl des Verkehrsmittels feiern und auch noch glauben, was ultimativ Neues gefunden zu haben.

Wird sie nicht. Bis jetzt gab es erst 2 Erweiterungen. Bei dieser Geschwindigkeit ist in den nächsten 5 Jahren nichts zu erwarten (vorausgesetzt, dass Sun, als treibende Kraft hinter Java, ihre Politik nicht ändern).

schreib' mir eine PM

Funktioniert in diesem Forum nicht.

Mit Zeigern zu programmieren ist Kampfjet-Fliegen. Dass Programmierer aus der Sandbox da abstürzen, ist in der Regel keine Fehlfunktion des Jets.

LOL

JBeni schrieb:

Haskell kann ich dir noch empfehlen. Wie Prolog, nur besser.

Kennst Du ein gutes Tutorial, ich wäre interessiert, da Du nicht der erste bist, der mich auf Haskell aufmerksam macht.

Ich finde A Gentle Introduction to Haskell ganz gut.

Informatiker werden immernoch gesucht.
Trotzdem finden viele Informatiker keine Arbeit.

Vielen fehlt es an Visionen. Das können Vorgesetzte kompensieren.
Den meisten fehlt das Verständnis, was sie da wirklich tun. Solche Leute programmieren auch C++ und man kann es ihnen leider nicht verbieten. Solche Leute mache ich verantwortlich für den inzwischen schlechten Ruf unter Nicht-C++-Programmieren.

Schön gesagt. Für C++ kann man auch Java einsetzen, passt genausogut.

[interpreter]

SIDEX schrieb:

jemand meinte hier dass c# besser sei weil es call by reference untertzützt? das ist quatsch mit souce sag ich nur!!!

Dein Textverständnis ist offensichtlich genauso schlecht wie deine sonstigen Ausführungen. Wenn du am Ende deines Studiums deinen Text nochmal liest, wirst du (wie ich jetzt) hoffentlich auch drüber schmunzeln können.

[JBeni]

SIDEX schrieb:

hallölchen

nun wollt ich mich hier mal auch bisschen abreagieren *g*

Dann sei herzlich Willkommen. Ich gebe dir mal ein bisschen Kanonenfutter weil ich nicht einschlafen kann.

zu sagen dass java so wundervoll ist weil es nun so schön platformunabhängig ist find ich unsiinig. ist denn c++ nicht platformunabhängig? ok dann muss ich eben paar zeilen code ändern und neu compilieren, und?

Und: du hast dann praktisch mehrere Programme (oder spielst dich mit Makros zu tode). Der Verwaltungsaufwand steigt.
Unser Prof meinte: "ein guter Programmierer ist faul." Mehr Verwaltungsaufwand widerspricht diesem Optimum.

und nun kom ich zu einem für mich sehr sehr verwirrenden teil in java

man kann java nähmlich sehr einfach in einem satz beschreiben:
beinahe jedes element seien es strings, arrays und und und, ist ein objekt, weil sie von der java.lang.object abstammen und erben und jedes objekt ist wiederum eine referenz.

- Jede Klasse erbt von java.lang.Object. Ein Array kann man hier als eine Art Spezialklasse anschauen. "int", "float", etc sind hingegen Primitive und haben ein anderes Verhalten.
- Jedes Objekt sitzt irgendwo im Speicher rum.
- Eine Variable im Quellcode wird zu einer Referenz zur Laufzeit und referenziert ein Objekt.

Eigentlich alles ganz einfach

so und nun sagt sun java ist sicherer, weil sie auf die zeiger verzichtet haben? LOOOOL *g* hier ist einfach alles eine referenz. echt respekt jungs, da haben die echt mal was geschafft. und die nullpointerexception nervt einen überhaupt nicht jede 5 sekunden.

Wenn du dein Programm richtig schreibst, nein, tun sie nicht
Eine Referenz der mit String angeschrieben ist, kann nicht plötzlich auf ein Wasabuduobjekt zeigen - in C++ durchaus möglich. Eine Referenz kann auch nicht irgendwo wild auf einen beliebigen (sinnlosen) Speicherbereich zeigen. Das ist doch um einiges sicherer.

soooooo, weiter gehts. kommen wir zu GC von java. okay ist n schönes teil, weil man nicht für jeden mist einen destruktor schreiben muss aber, dass eine maschiene es besser machen kann als der mensch, glaub ich einfach nicht.

Ohne GC: du musst sicherstellen dass ein Objekt erst abgeräumt wird, wenn es von niemandem mehr benutzt wird.
Mit GC: das Objekt wird automatisch abgeräumt wenn es von niemandem mehr benutzt wird.

Jetzt erklär mir mal wie du in "etwas sicherstellen" weniger Fehler machen kannst als in "<empty>"?

Dass man bei einem GC zuerst alle Referenzen kappen muss, ist ein anderes Thema (Speicherlecks kann man in Java wie in C++ ohne grösseren Aufwand generieren).

ist java denn so perfekt und nichts verwirrendes beinhaltet, nur weil es dort keine zeiger und mehrfachvererbung gibt? java kann z.B: mit den ganzen klammern nur so vor sich hin spucken, da soll mal einer klar kommen.

Es gibt z.B. auch kein Operatoroverloading, Templates oder Funktionspointer. Ja, mit der Beschränkung auf weniger Syntaxelemente ist Java eindeutig übersichtlicher. Perfekt ist es deswegen nicht, eine perfekte Programmiersprache gibt es derzeit nicht.
Für dein Klammernproblem: Codeeinrückung lautet das Zauberwort

[Kritiker]

SIDEX schrieb:

also ich muss sagen als ich erste schritte in java gemacht habe, konnte ich schon von der sprache fast kotzen. die schönen sprüche dass java c++ sehr ähnlich sei haben mir am anfang hoffnung gemacht aber jetzt würde ich jeden umbringen der das noch mal behauptet.
ohne genau zu werden muss ich als erstes sagen unter c++ hatte ich einfach das gefühl mehr kontrolle über meinen rechner zu haben.

Aha, jetzt musst Du nur noch definieren was Du mit "ähnlich" meinst. Und ja, die Syntax ist sehr ähnlich. Wodurch hast Du in C++ mehr kontrolle über Deinen Rechner, nur durch Zeiger? Dir ist klar das Referenzen vom Prinzip her nichts anderes als Zeiger sind? Dir ist auch klar, dass man in C++ ebenfalls wann immer möglich Referenzen Zeigern vorziehen sollte?

SIDEX schrieb:

zu sagen dass java so wundervoll ist weil es nun so schön platformunabhängig ist find ich unsiinig. ist denn c++ nicht platformunabhängig? ok dann muss ich eben paar zeilen code ändern und neu compilieren, und? java im vergleich zu c# ist aber wiederum besser, weil nun wirklich platformübergreifend ist.

Es programmiert keiner nur aus dem Grund in Java weil es plattformunabhängig ist. Aber es ist ein Grund der mitunter eine wichtige Rolle einnehmen kann. Anscheinend hast Du noch nie versucht ein etwas größeres Programm unter Windows, Linux, BSD und SVR4 zu laufen zu bringen. Sonst wüsstest Du was Java hierbei so attraktiv macht.

SIDEX schrieb:

man kann java nähmlich sehr einfach in einem satz beschreiben:
beinahe jedes element seien es strings, arrays und und und, ist ein objekt, weil sie von der java.lang.object abstammen und erben und jedes objekt ist wiederum eine referenz.

Das nennt sich OOP. In diesem Fall nicht immer glücklich, aber es hat in der Praxis einfach viele Vorteile.

SIDEX schrieb:

so und nun sagt sun java ist sicherer, weil sie auf die zeiger verzichtet haben? LOOOOL *g* hier ist einfach alles eine referenz. echt respekt jungs, da haben die echt mal was geschafft. und die nullpointerexception nervt einen überhaupt nicht jede 5 sekunden.

Wo hat Sun das geschrieben?
BTW: Wenn Du in Java NullPointerExceptions bekommst, bekommst Du in C++ in der gleichen Situation einen SegFault. Das ist ein reiner Programmierfehler, der nichts mit Java oder C++ zu tun hat.

SIDEX schrieb:

soooooo, weiter gehts. kommen wir zu GC von java. okay ist n schönes teil, weil man nicht für jeden mist einen destruktor schreiben muss aber, dass eine maschiene es besser machen kann als der mensch, glaub ich einfach nicht. ausserdem tuen manche so als ob es keinen für c++ gäbe. hab zwar noch nie einen benutzt aber gehört habe ich schon mal davon, zumindest, dass es in entwicklung ist.

GC ist kein Allheilmittel, aber er ist in bestimmten Situationen für die Performance sogar wichtig, da der Programmierer zur Entwicklungszeit nicht abschätzen kann, wann auf dem spezifischen System ein guter Zeitpunkt erreicht ist(nein ich meine keine Client-Anwendungen auf x86).

SIDEX schrieb:

ok noch ein nachteil von java: schon mal gesehen wie ein array von der JVM implementiert wird? nein? okay ein beispiel:

int[] lahmarsch = { 1, 2, 3 };

//und so siehts dann aus

int[] lahmarsch = new int[3];
lahmarsch[0] = 1;
lahmarsch[1] = 2;
lahmarsch[2] = 3;

juhu und jetzt stellt euch mal nen mille-array vor. ich weiß zwar nicht genau aber ich vermute mal in c++ wird es anders behandelt. so und java soll schneller sein? wieder mal quatsch mit souce

Der ging mal wieder nach hinten los. Der Thread Titel heisst übrigens auch "Warum Java vom Prinzip her schneller als C++?" und nicht "Java ist schneller". Wenn Du wirklich mal repräsentative Beispiele für die Performance und Einsatzgebiete in Java sehen möchtest, dann schau Dir mal J2EE an. So nennt sich dass Zeug was die in der Java-Praxis häufig verwenden.

SIDEX schrieb:

ahhh noch was vergessen. ich habe schon oft gesehen dass die java-fans sich über zeiger-auf-zeiger in c++ beschwerrt haben weil es so verwirrend war. dazu muss ich ne frage stellen: ist java denn so perfekt und nichts verwirrendes beinhaltet, nur weil es dort keine zeiger und mehrfachvererbung gibt? java kann z.B: mit den ganzen klammern nur so vor sich hin spucken, da soll mal einer klar kommen.

Ich habe wie die meisten anderen auch keine Probleme mit Zeigern auf Zeigern auf ein Array von Funktionszeigern die als Parameter wiederum Zeiger auf Funktionen bekommen.

Die guten Java Programmierer haben alle einen Background in vielen anderen Sprachen, dass ist für jeden Programmierer einfach unabdingbar. Ehrlich gesagt, finde ich Zeiger sogar sehr einfach. Schon mal Assembler programmiert?

Meine persönliche Sprache der Wahl ist C(manchmal auch C++). Aber in der Praxis ist Java einfach nur genial! Du hast viel zu wenig Zeit mit viel zu wenig guten Programmierern und must bis zu einem Stichtag eine Anwendung präsentieren. Das ist einer der Gründe warum Java so erfolgreich ist!

[Manuelh87]

JBeni schrieb:

Wenn du dein Programm richtig schreibst, nein, tun sie nicht
Eine Referenz der mit String angeschrieben ist, kann nicht plötzlich auf ein Wasabuduobjekt zeigen - in C++ durchaus möglich. Eine Referenz kann auch nicht irgendwo wild auf einen beliebigen (sinnlosen) Speicherbereich zeigen. Das ist doch um einiges sicherer.

Wenn du richtig schreibst... dann passiert das auch in c++ nicht!

Überhaupt möchte ich sagen das man Äpfel nicht mit (fetten langsamen ) Birnen vergleichen kann...
Beide Sprachen haben vorteile:
Ich könnte in java ein programm erstellen und mir sicher sein dass es so sofort auf einem anderen system läuft (einzige voraussetzung die JVM, ist aber eh klar); das ist ein völlig anderer ansatzpunkt als bei c++. Ich finde dieses Möglichkeit gibt java durchaus eine Berechtigung.

Aber da c++ native compiliert wird, ist es ja wohl offensichtlich dass java als interpretierte sprache nie so schnell sein kann... -> niemals!!!
Außer natürlich man schreibt sein c++ programm so ineffektiv und langsam wie möglich. Man kann alle (wirklich alles) optimierungen die die JVM je machen könnte auch in sein c++ programm einbauen. Kann ja auch ne VM machen mit c++. Von daher kann sich java beim vergleich mit c++ auf einem bestimmten system *immer* brausen! Noch dazu hat mir bis jetzt niemand zeigen können was die JVM echt optimieren kann, was nicht aus einem programmierfehler ausgeht. hab mal als beispiel eine schleife bei der einen funktion die einen fixen wert zurückbekommt bei jedem durchlauf aufgerufen wird bekommen. Tja, und wo optimiert die JVM da was? Sie macht höchsten den fehler des programmierers weg. Also "optimiert ihn raus"; man könnte ihn aber auch einfach vermeiden...

Also sry, aber es ist sinnlos eine interpreter sprache gegen eine mit nativ code antreten zu lassen... Und diese laufzeitoptimierung, naja bin kein großer fan von ihr, denn die verbraucht ja auch bei der analyse performance und ja, wie gesagt, hab eigentlich noch kein richtig gutes bespiel wo sie optimiert gesehen, außer eben solche "fehler" die man ja auch einfach ausbessern kann.

Damit red ich ja niemandem java aus. Nur ich kann irgendwie nicht mit java arbeiten weil mir einfach zu viel flexibilität abgehen würde, und auch der ganze syntax den ich so liebgewonnen hab ...
Aber wenn mich das nicht so stören würde, sag ich euch würd ichs gscheit lernen und auch benutzen, denn der fakt das es dann auf fast allen systemen ohne neu kompilieren läuft, ist find ich, auch ne ganze menge wert.

in diesem sinne... (und streitet euch nicht zu viel )
mfg Manuel

[Gast]

SIDEX schrieb:

bitte schön:

http://www.galileocomputing.de/openbook/javainsel/java-03.htm#Xxx279093

aber krieg keine überdosis

Naja, du kannst nicht verlangen, dass du in Java genauso programmieren kannst wie in C++, bei gleicher Effizienz. Ich gehe mal davon aus, du willst lokal in einer Funktion ein Array mit den immer selben Startwerten, die sich aber nachher ändern. Wenn sie sich nicht ändern würden, wäre es ziemlich dämlich, das immer gleiche Array neu anzulegen.
In diesem Fall machst du einfach ein statisches Array mit den Startwerten und klonst es jedesmal. Das kann nicht wesentlich langsamer sein, weil auch wenn das Array in C++ auf dem Stack liegt, müssen irgendwie die Werte zugewiesen oder auf den Stack kopiert werden.

so kostet die Zuweisung sehr viel Laufzeit, da wir viele Zugriffe haben, die auch alle schön durch die Index-Überprüfung gesichert sind

Das ist natürlich Blödsinn. Sowas optimiert die VM wahrscheinlich seit 1.3 schon weg. Ebenso wie du nicht glauben brauchst, dass in einer einfachen for-Schleife, die bis zur Array-Länge läuft, bei jedem Zugriff die Index-Prüfung stattfindet.

Daher ist davon abzuraten, etwa Bilder oder große Tabellen im Programmcode zu speichern.

Und das bedarf sowieso keines weiteren Kommentars. Fazit: Ich steige wieder auf meine alten Drogen um.

[Kritiker]

Manuelh87 schrieb:

Also sry, aber es ist sinnlos eine interpreter sprache gegen eine mit nativ code antreten zu lassen... Und diese laufzeitoptimierung, naja bin kein großer fan von ihr, denn die verbraucht ja auch bei der analyse performance und ja, wie gesagt, hab eigentlich noch kein richtig gutes bespiel wo sie optimiert gesehen, außer eben solche "fehler" die man ja auch einfach ausbessern kann.

Java wird ist keine klassische Interpretersprache! Java ist zur Laufzeit im Speicher genauso Maschinencode, wie C++. Es hat nur halt den einmaligen overhead, der aber in der Praxis(und den richtigen Einsatzgebieten vorausgesetzt) überhaupt keine Rolle spielt!
http://java.sun.com/products/hotspot/docs/whitepaper/Java_Hotspot_v1.4.1/Java_HSpot_WP_v1.4.1_1002_1.html

Kann das sein, dass ihr alle Java nur in falschen Anwendungsgebieten seht? Du willst ein gutes Beispiel für Performance in Java?

http://de.bea.com/index.jsp
http://www.jboss.org
http://www.sap.com/germany/index.epx

Warum wird auch immer nur eclipse genommen? Was ist mit dem JDeveloper, NetBeans oder dem Sun Java Studio? Das mit eclipse ist ein alter Hut. Das ist genauso als wenn ich für die häufigen Probleme eines bekannten Browsers die Programmiersprache verantwortlich mache. Es kommt immer auf den Programmierer an!

[Manuelh87]

Kritiker schrieb:

Java ist zur Laufzeit im Speicher genauso Maschinencode, wie C++.

NEIN!

das was die mit byte-code meinen ist NICHT Maschinencode!!!

hast wohl deinen eigenen text nicht ganz verstanden... was macht dann deiner meinung nach die virtual maschine? java liegt eben nicht in native code for sondern in einem code der dann von der JVM interpretiert wird. Damit hab ich ja ned gmeint dass er geparst wird, also so wie halt auf html seiten. natrülich wird java code "compiliert" so wie auch .net "compiliert" wird. Aber in keinen maschinen (=native) code sondern in ich nenns mal java-code. dieser wird dann von der virtual maschine umgesetzt.

Und darum muss er ja langsamer sein oder maximal gleichschnell... also bei perfekter umsetzung... das ist ja wohl logisch.

mfg Manuel

[JBeni]

*sorry, hier stand Mist*