c++ vs. java... was hat zukunft

Konrad Rudolph

pale dog schrieb:

Gerade bei Simulationen oder Auswertungen kann man schnell auf sehr große Datenmengen kommen. (Frag zB mal einen Bioinformatiker oder jemand der Datamining betreibt nach den üblichen Datenmengen die er abarbeitet)

sowas holt man sich doch nicht am stück in den speicher

Lies mein betreffendes Posting. Bei Datenbanken holt man sich das sehr wohl am Stück in den Speicher.

pale dog

Konrad Rudolph schrieb:

Lies mein betreffendes Posting.
Bei Datenbanken holt man sich das sehr wohl am Stück in den Speicher.

die laufen aber auf speziell dafür eingerichteten servern, ne?
auf 'ner 'normalen' pc-gurke mit windows-xp home/professional oder klicki-bunti linux/kde, wo auch nebenbei noch andere progrämmchen laufen wollen, stell ich mir das ganz schön lahm vor.

darthdespotism

DEvent schrieb:

Ihr versteht mich total falsch. Was ich meinte ist das sich die neue VM dann auf 64bit Register einstellen kann. Das neuere, schnellere Maschinencode produziert werden kann. Das man z.B. die Funktion sqrt() auf zukünftige Maschinen vielleicht in einem einzigen Zyklus berechnen kann.

Davon profitieren statisch kompilierte Programme nicht. Verbraucht sqrt() heute vielleicht 30 Tankzyklen, wird in 10 Jahren sqrt() vielleicht in 2 ausgeführt. Dein statisches kompiliertes Programm wird aber in aller Ewigkeiten 30 Zyklen für sqrt() verbrauchen.

Stimmt so nicht ganz. Erstens mal ist ein asm-Befehl nicht ein Taktzyklus, das kann sich auch mit der Zeit ändern und viel wichtiger: Moderne Prozessoren können einiges an optimierung dürchführen. In ihren x86 JIT-Compilern Wir verwenden halt unsere Hardware-VM

Konrad Rudolph

pale dog schrieb:

Konrad Rudolph schrieb:

Lies mein betreffendes Posting.
Bei Datenbanken holt man sich das sehr wohl am Stück in den Speicher.

die laufen aber auf speziell dafür eingerichteten servern, ne?

Meistens ja, natürlich. Aber nicht nur.

auf 'ner 'normalen' pc-gurke mit windows-xp home/professional oder klicki-bunti linux/kde, wo auch nebenbei noch andere progrämmchen laufen wollen, stell ich mir das ganz schön lahm vor.

Hmm. Man braucht natürlich ein paar RAM-Bausteine. Ob das so unter WinXP geht, weiß ich auch nicht aber unter Linux ist es durchaus machbar – und *wird* gemacht. Man sollte es dann natürlich tunlichst vermeiden, nebenbei noch große Anwendungen laufen zu lassen.

Phoemuex

DEvent schrieb:

Da ist C++ inkonsistenter:
int a = new(5);
Ist a jetzt ein Objekt? Es hat aber keine Methode oder Attribute.

Erstmal fehlt da ein Sternchen, da es ja ein Zeiger sein muss :p

int *a = new int(5);

Und (mehr oder weniger) gibt es Methoden, nämlich operator=, operator-, operator+...

Natürlich würde man, wenn man nur mit einem int arbeiten will keine Zeiger verwenden (genauso wie das eigentlich auch bei "wirklichen Objekten" sinnlos ist ). Also so:

int a = 5;

Felix

P.S.: Eine Sprache in der das wirklich konsistent ist, ist Python

EDIT: Irgendwie vertragen sich die cpp und die bold-Tags nicht...

google anzeigen schrieb:

Java Installer Builder
Easy to use, amazingly powerful Creates beautiful installers

Fencer

Kann vielleicht irgendein Moderator diesen Thread schließen?
(Sonst geht das hier ewig weiter )

CStoll

pale dog schrieb:

CStoll schrieb:

Ja, soweit ist das klar. Und genau die Tatsache, daß die Java-Variablen eben keine Objekte sind (sondern "nur" Referenzen), mußt du im Hinterkopf behalten, wenn du mit Java arbeitest. (und dazu noch den Unterschied zwischen einem 'int x' und einem 'MyType x')

ja, natürlich sollte man eine programmiersprache und ihre eigenheiten kennen, wenn man sie anwenden will. ...und ich nehme doch stark an, dass ich dir hiermit nichts neues erzähle

CStoll schrieb:

Btw, was ist der konzeptionelle Unterschied zwischen einem "MyObject.AddValue(4);" und "MyInt+=4;"?

das weiss ich nicht, weil ich 'MyObject' nicht kenne.

OK, dann sage ich dir noch dazu, daß MyObject eine selbstgeschriebene BigInt-Klasse sein könnte. Aber um die Innereien der Klasse geht es hier nicht:

MyIntType bi = new MyIntType(4711);
MyIntType bi2 = bi;
bi.Add(4);//das ändert sowohl den Wert von bi als auch von bi2

int si = 4711;
int si2 = si;
si+=4;    //das ändert NUR si - si2 behält den Wert 4711

Kannst du mir erklären, warum technisch identische Anweisungen (wenn es ginge, hätte ich die Methode Add() als operator+= implementiert) so unterschiedliche Auswirkungen haben? Das ist die Inkonsistenz, die du als Java-Nutzer immer beachten mußt.

Simon2 schrieb:

Es gibt 2 "Sorten von Variablen" - die eine hält einen primitiven Typen und die andere eine Referenz/Pointer auf ein Klassenobjekt.

das würde ich nicht einfach so zweigeteilt sehen. unter Java gibt es verschiedene typen wie longs, floats, boolean, strings, etc. ...und eben referenzen, jeder datentyp hat seine speziellen eigenschaften und muss nicht mit den anderen verwandt sein.

Du kannst das gerne auf dieser unteren Ebene aufdröseln. Aber für den Programmierer sind die Referenzen uninteressant und eher die dahinterstehenden Klassen von Bedeutung. Und da bleibt die Zwei-Klassen-Gesellschaft "primitive Typen" (int, float etc - inklusive Referenz) vs "Klassen"

@Fencer: Ja, da könntest du Recht haben - das dreht sich seit einer halben Ewigkeit im Kreis (vermutlich das vorbestimmte Schicksal JEDES "Java vs C++" Threads).

Konrad Rudolph

CStoll:

Ich weiß nicht, ob es sinnvoll ist, eine Argumentation gegen die Unterscheidung von Referenz- und Wertetypen in einer Sprache zu führen. Sicher, Dein Kritikpunkt trifft ins Schwarze. Trotzdem scheint die allgemeine Ansicht ja zu sein, dass die Vorteile die Nachteile aufwiegen – man muss sich nur anschauen, wieviele der neuen Sprachen solch eine Unterscheidung anbieten.

In .NET finde ich das recht gut gelöst, da könnte man BigInt als Structure implementieren und hätte seinen Wertetypen, der sich genauso verhält wie die eingebaute Integer-Klasse. (Wobei, wenn ich mich recht erinnere, habe ich neulich im MSDN-Entwicklerblog gelesen, dass die Dödel dort den Bignum-Datentyp als Klasse implementiert haben. Kann mich aber auch irren.)

Viel schlimmer finde ich, dass man Wertetypen in Java nicht vollwertig benutzen kann, z.B. was das Zusammenarbeiten mit generischen Klassen betrifft (man versuche mal, eine 'ArrayList<int>' zu erstellen). Dass hier Boxing vonnöten ist – und dann auch noch von Hand! – das ist doch schon eine enorme Einschränkung.

Gregor

Konrad Rudolph schrieb:

Viel schlimmer finde ich, dass man Wertetypen in Java nicht vollwertig benutzen kann, z.B. was das Zusammenarbeiten mit generischen Klassen betrifft (man versuche mal, eine 'ArrayList<int>' zu erstellen). Dass hier Boxing vonnöten ist – und dann auch noch von Hand! – das ist doch schon eine enorme Einschränkung.

Von Hand? Wie meinst Du das? ...ansonsten stimme ich Dir aber zu: Man muss die Motivation betrachten, mit der Generics zu Java hinzugefügt wurden. Damals ging es um statische Typsicherheit. Das wurde im Großen und Ganzen erreicht. ...andere Aspekte wurden halt nicht erreicht. Aus meiner Sicht stellt die fehlende Generizität bezüglich primitiver Datentypen vor allem ein Performanceproblem dar.

Schade, dass man damals keine "große Lösung" angestrebt hat. Aber so ist das halt: Java ist in seiner Entwicklung nur begrenzt flexibel. Es gibt allerlei Interessen, die unter einen Hut zu bringen sind. Vor allem wären damals bei einer "großen Lösung" massive Änderungen am Bytecode nötig gewesen, die man den verschiedenen Anbietern von JVMs wohl nicht zumuten konnte.

Naja, bei C++ läuft es diesbezüglich aber auch nicht gerade besser. Eher schlechter. ...viel schlechter. Da gibt es seit fast 10 Jahren praktisch gar keine Resultate aus der Weiterentwicklung.

Simon2

DEvent schrieb:

...

Damit sind wir wieder bei der Diskussion aus dem anderen Thread - wo wir uns auch schon nicht einig wurden. Wird hier wohl auch nicht besser werden.
Letztlich bleibt es: Es gibt 2 "Sorten von Variablen" - die eine hält einen primitiven Typen und die andere eine Referenz/Pointer auf ein Klassenobjekt.
Bei dem einen

erzeugt man "Dinge auf die sie verweisen" mit new,
kann sie "umhängen" und
null-en,

beim anderen nicht.
Zweitere kann man dafür "typspezifisch manipulieren" (mit 7 multiplizieren oder Buchstaben anhängen ...) , was mit ersteren nicht geht.
Kann man mögen/konsistent finden oder nicht.

Es ist konsistent. MyClass klasse; ist ein Objekt, ...

Ich dachte, das ist eine Referenz ? Das war es jedenfalls, was hier die Javaisten in der Diskussion immer wieder vorbeten !

DEvent schrieb:

...
Da ist C++ inkonsistenter:
int a = new(5);
Ist a jetzt ein Objekt? ...

Weder noch: Das ist falsch !
Wenn schon, dann

int* a = new(5);

außerdem: Es gibt diese Unterscheidung in C++ eben NICHT ! Das ist genau die "Javadenke", die C++ nicht nötig hat.
Du hast hier eine Variable mit einem bestimmten Typen.
Fertig.

Gruß,

Simon2.

tntnet

Gregor schrieb:

Naja, bei C++ läuft es diesbezüglich aber auch nicht gerade besser. Eher schlechter. ...viel schlechter. Da gibt es seit fast 10 Jahren praktisch gar keine Resultate aus der Weiterentwicklung.

Das sehe ich als grossen Vorteil. Bereits vor 10 Jahren war die Sprache ausgereift und die Programme, die damals geschrieben wurden, funktionieren auch heute noch. Das nenne ich Investitionsschutz. Das ist auch der Hauptgrund, warum heute noch Cobol und Fortran verwendet werden.

CStoll

Gregor schrieb:

Schade, dass man damals keine "große Lösung" angestrebt hat. Aber so ist das halt: Java ist in seiner Entwicklung nur begrenzt flexibel. Es gibt allerlei Interessen, die unter einen Hut zu bringen sind. Vor allem wären damals bei einer "großen Lösung" massive Änderungen am Bytecode nötig gewesen, die man den verschiedenen Anbietern von JVMs wohl nicht zumuten konnte.

Eben Dem ist wohl kaum etwas hinzuzufügen.

Naja, bei C++ läuft es diesbezüglich aber auch nicht gerade besser. Eher schlechter. ...viel schlechter. Da gibt es seit fast 10 Jahren praktisch gar keine Resultate aus der Weiterentwicklung.

TR1 ist afaik schon da (auch wenn es noch nicht jeder Compiler anbietet) und die nächste Version des Standards ist auch auf dem Weg.

@Konrad: Ich hab' weder etwas gegen Wertsemantik noch gegen Referenzsemantik. Es ist nur etwas unglücklich, die Möglichkeiten anhand des Datentyps fest vorzugeben (in C++ kann ich als Programmierer selber entscheiden, was ich mit meinen Daten machen will). Die Möglichkeit von C#, wahlweise struct (Werttyp) oder class (Referenztyp) anzulegen, geht da schon in die richtige Richtung - aber in Java fehlt die Möglichkeit komplett, eigene Typen mit Wertsemantik zu definieren.

pale dog

CStoll schrieb:

MyIntType bi = new MyIntType(4711);
MyIntType bi2 = bi;
bi.Add(4);//das ändert sowohl den Wert von bi als auch von bi2

nein , ach menno , du verstehst es einfach nicht...
das

bi.Add(4);

verändert weder den wert von bi noch den wert von bi2
beide referenzen verweisen weiterhin auf das eine MyIntType-objekt.

rüdiger

Gregor schrieb:

Naja, bei C++ läuft es diesbezüglich aber auch nicht gerade besser. Eher schlechter. ...viel schlechter. Da gibt es seit fast 10 Jahren praktisch gar keine Resultate aus der Weiterentwicklung.

Und was ist mit dem 2003-Standard oder dem TR1? Also seit weniger als einem Jahr gibt es keine Resultate. Ach und dann gibt es ja noch den laufenden Standardisierungs-Prozess der ja schon erste Früchte abwirft, wenn man sich den GCC 4.3 oder ConceptGCC anschaut. Das in der C++-Welt sorgfältiger entschieden wird sehe ich eher als Vorteil an. Gerade die Generics zeigen doch was passiert, wenn man schnell schnell ein Feature mit dem x.y-Release rausbringen will, weil es die Sprache Z (hier eben C#) schon hat.

Und so hat man ja auch das Problem, dass die Sprache schon weiter ist, als die meisten Nicht-SUN-SDKs. IBM setzt ja immer noch auf Java 1.4.

Gregor

tntnet schrieb:

Gregor schrieb:

Naja, bei C++ läuft es diesbezüglich aber auch nicht gerade besser. Eher schlechter. ...viel schlechter. Da gibt es seit fast 10 Jahren praktisch gar keine Resultate aus der Weiterentwicklung.

Das sehe ich als grossen Vorteil. Bereits vor 10 Jahren war die Sprache ausgereift und die Programme, die damals geschrieben wurden, funktionieren auch heute noch. Das nenne ich Investitionsschutz. Das ist auch der Hauptgrund, warum heute noch Cobol und Fortran verwendet werden.

Blabla. C++ ist eben nicht ausgereift. Nicht vor 10 Jahren, nicht jetzt und auch nicht nach dem nächsten Standard. Und das gilt auch für jede andere Sprache. ...Einsicht wäre der erste Weg zur Besserung! Nimm die Concepts: von denen hört man oft in Verbindung mit dem neuen Standard. Warum hat C++ die plötzlich nötig? Weil es schon vor 10 Jahren ausgereift war?

@CStoll: Slange der Standard nicht da ist, ist es kein wirkliches Resultat. Es gibt auch jede Menge experimentelle Erweiterungen für Java, die man diskutieren könnte.

CStoll

pale dog schrieb:

CStoll schrieb:
MyIntType bi = new MyIntType(4711);
MyIntType bi2 = bi;
bi.Add(4);//das ändert sowohl den Wert von bi als auch von bi2
nein , ach menno , du verstehst es einfach nicht...
das
bi.Add(4);
verändert weder den wert von bi noch den wert von bi2
beide referenzen verweisen weiterhin auf das eine MyIntType-objekt.

Nein, du verstehst mich nicht: dem Anwender ist die "Referenz bi" egal (und nur ein Mittel zum Zweck) - für ihn zählt das "Objekt bi" (in C++ hätte ich das als MyIntType* bi = new MyIntType(4711); geschrieben und könnte jetzt klarer unterscheiden zwischen dem Zeiger bi und dem Objekt *bi). Und die "Objekte" bi und bi2 sind nunmal identisch - im Gegensatz zu den "Objekten" si und si2.

pale dog

CStoll schrieb:

dem Anwender ist die "Referenz bi" egal (und nur ein Mittel zum Zweck) - für ihn zählt das "Objekt bi"

mittel zum zweck natürlich schon, aber egal trotzdem nicht. man kann z.b. das objekt wegschmeissen mit 'bi = null; bi2 = null;', man kann bi oder bi2 auf ein neues objekt verweisen lassen usw. usw...

CStoll schrieb:

(in C++ hätte ich das als MyIntType* bi = new MyIntType(4711); geschrieben und könnte jetzt klarer unterscheiden zwischen dem Zeiger bi und dem Objekt *bi).

denk dir in Java das sternchen weg, dann stimmt's ja fast.
...oder versuch dich mal von dieser schrecklichen C++ sichtweise zu lösen, vielleicht fällt dir das verständnis dann leichter...

CStoll schrieb:

Und die "Objekte" bi und bi2 sind nunmal identisch - im Gegensatz zu den "Objekten" si und si2.

bi, bi2, si und si2 sind im sinne von Java keine objekte.

CStoll

pale dog schrieb:

CStoll schrieb:

dem Anwender ist die "Referenz bi" egal (und nur ein Mittel zum Zweck) - für ihn zählt das "Objekt bi"

mittel zum zweck natürlich schon, aber egal trotzdem nicht. man kann z.b. das objekt wegschmeissen mit 'bi = null; bi2 = null;', man kann bi oder bi2 auf ein neues objekt verweisen lassen usw. usw...

Möglich. Aber das ist nicht der Hauptzweck meiner Klassen Meine Klasse soll (z.B.) rechnen können und sich dabei möglichst genauso verwenden lassen wie die eingebauten int's - und jetzt verrat mir mal, wie du das hinbekommen willst.

CStoll schrieb:

(in C++ hätte ich das als MyIntType* bi = new MyIntType(4711); geschrieben und könnte jetzt klarer unterscheiden zwischen dem Zeiger bi und dem Objekt *bi).

denk dir in Java das sternchen weg, dann stimmt's ja fast.

Deswegen bleibt immer noch der Unterschied zwischen der Referenz bi und dem Objekt bi (in C++ *bi) - und die Frage, welche Operationen sich nun auf was beziehen.

...oder versuch dich mal von dieser schrecklichen C++ sichtweise zu lösen, vielleicht fällt dir das verständnis dann leichter...

Versuch du doch mal, dich von "dieser schrecklichen Java sichtweise" zu lösen, dann verstehst du womöglich auch die Argumente der Gegenseite.

CStoll schrieb:

Und die "Objekte" bi und bi2 sind nunmal identisch - im Gegensatz zu den "Objekten" si und si2.

bi, bi2, si und si2 sind im sinne von Java keine objekte.

Und da behauptet Java immer, objektorientiert zu sein

@Gregor: Und Java ist ausgereift? Nur die Tatsache, daß die Entwickler dort häufiger neue Versionen definieren, ist noch lange kein Zeichen für Qualität. Das C++ Kommitee durchdenkt die Verbesserungen halt gründlicher anstatt solche Schnellschüsse herauszubringen (die dann auf ewig im Sprachkonzept zurückbleiben).

Simon2

pale dog schrieb:

...man kann z.b. das objekt wegschmeissen mit 'bi = null; bi2 = null;', man kann bi oder bi2 auf ein neues objekt verweisen lassen usw. usw......

Naja ... "usw" ist schon ein wenig übertrieben. Mehr, als auf ein Objekt oder null verweisen und "calls weiterzureichen" zu lassen, kann man mit einer Referenz nicht machen.
Selbst "Wegschmeissen" geht eigentlich nicht; man kann höchstens "vergessen, dass man es kannte" (der GC kann es, wenn er Lust dazu hat, irgendwann wegschmeissen).

So eine Referenz ist schon ein recht beschränktes Ding.

Gruß,

Simon2.