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

pale dog

rüdiger schrieb:

Wie ist das eigentlich bei Java, da es ja keine Vorzeichenlosen-Integer-Typen gibt. Kann man überhaupt 32Bit voll ausnutzen? Ich nehme mal an, das bei x < 0 eine Exception geworfen wird. Ansonsten kann man ja sicher ne Menge lustiger Integer-Exploits bei Java-Programmen durchführen.

bei negativen oder zu grossen indizes gibt's ne 'IndexOutOfBounds' exception (oder so ähnlich heisst die).
man kann die 32 bits nicht voll als index ausnutzen, d.h. ein byte-array kann max. 2GB gross sein.

DEvent

tntnet schrieb:

pale dog schrieb:

nochmal die frage: wieso sollte man ein bestehendes und funktionierendes programm auf einen breiteren datentyp umstellen wollen, wenn es mit dem bisherigen datentyp problemlos läuft?
ich kann mir höchstens vorstellen, dass man sich irgendwo vertan hat und überläufe bekommt, so dass man ein oder zwei funktionen abändern muss, aber es wird doch niemand in einem kompletten (und eventuell recht grossen) programm auf die idee kommen, alles 'ints' in 'longs' o.ä. umzuändern.
wozu soll das gut sein

Man stelle sich beispielsweise ein Grafikprogramm vor (oder ein anderes Programm, welches sehr viele Daten hält). Ich habe meine Daten in einem Array. Der Index auf dieses Array ist in einer int-Variablen. Jetzt habe ich irgendwann eine Maschine mit mehr als 4 GB Arbeitsspeicher, was mir ermöglicht, noch grössere Datenstrukturen zu verwalten. Bei Java verbietet sich das, da mein Index ja 32 Bit ist. Bei C++ habe ich micht nicht festgelegt. Sobald ich mein Programm unter 64 Bit übersetze, kann ich meinen Arbeisspeicher auch ausnutzen.

Wieso diskutiert ihr überhaupt das man ein Array mit über 4 Gigs haben kann? Wer nimmt den für solch große und vor allem dynamischen Größen ein statisches Array?

Ein Nachteil ist wirklich das man in Java für solche Methode wie size() oder length() ein int als Rückgabetyp nimmt. Man hätte hier wirklich ein size_t wie in C++ nehmen sollen.

Voraussetzung ist natürlich, daß ich die Datentypen korrekt verwende. Int ist eben auch auf 64 Bit nur 32 Bit. Daher hätte ich sicher size_t verwenden sollen. Oder ich habe von vorneherein ein typedef. Dann muß ich diesen halt ändern (und nur diesen). Das ist übrigens auch ein Feature, was in Java fehlt.

Ich denke, man muß 2 Fälle unterscheiden, wenn man über die Vor- und Nachteile von festgelegten Datengrössen diskutiert. Manchmal will ich explizit eine bestimmte Grösse, dann nehme ich unter C++ int32_t oder int64_t oder was auch immer. Manchmal brauche ich halt nur eine Ganzzahl und die Grösse ist mir egal. Dann nehme ich int. Das hat den weiteren Vorteil, daß der Leser des Codes weiß, daß der Programmierer genau einen 32-Bit-Wert meint oder eben nicht.

Du willst doch nicht wirklich Daten variabler Länge und über 4Gigs in ein Array speichern? Das war sicherlich ein Scherz oder?

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.

...Sonst versteht man doch nicht, dass man hier nur ein einziges Objekt hat: Java Code:
class XYZ
{
//...
}
XYZ myXYZ = new XYZ;
XYZ myXYZ2 = myXYZ; //OH, nur ein Objekt, normalerweise würde man ja denken, es wäre kopiert...
int myInt = 1;
int myInt2 = myInt; //OH, nur ein Objekt, wenn das oben kein Zeiger ist, wieso ist es dann hier anders?
Java Code:
class XYZ
{
//...
}
XYZ myXYZ = new XYZ;
XYZ myXYZ2 = myXYZ; //OH, nur ein Objekt, normalerweise würde man ja denken, es wäre kopiert...
int myInt = 1;
int myInt2 = myInt; //OH, nur ein Objekt, wenn das oben kein Zeiger ist, wieso ist es dann hier anders?

Wirklich Zeiger braucht man dafür nicht. In Java ist es eindeutig definiert was ein Objekt ist und was nicht.

Edit: Ups blöd gequoted

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, int x = 5; ist kein Objekt. Nur von Klassen kann man Objekte erzeugen, von primitiven Typen nicht.

Da ist C++ inkonsistenter:

int a = new(5);

Ist a jetzt ein Objekt? Es hat aber keine Methode oder Attribute.

Mr. N

Es ist illusorisch zu glauben, man könnte ein Binary 10 Jahre lang verwenden. Es sei denn irgendwelches obskures VMX-Zeugs.

rüdiger

DEvent schrieb:

Wieso diskutiert ihr überhaupt das man ein Array mit über 4 Gigs haben kann? Wer nimmt den für solch große und vor allem dynamischen Größen ein statisches Array?

Klar gibt es Fälle wo man so etwas braucht. 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)

DEvent

rüdiger schrieb:

DEvent schrieb:

Wieso diskutiert ihr überhaupt das man ein Array mit über 4 Gigs haben kann? Wer nimmt den für solch große und vor allem dynamischen Größen ein statisches Array?

Klar gibt es Fälle wo man so etwas braucht. 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)

Ein Array? Ein statisches Array?
Also sowas:

int[] array = new int[4 * 1048576];

Ich dacht ich hätt es schon geschrieben in meinem vorigem Posting. Naja nochmal: Es ist wirklich ein Nachteil das die Methoden wie size() und length() von Java ein int als Rückgabewert haben. Besser wäre es wohl ein size_t zu haben wie in C++.

finix

DEvent schrieb:

Wirklich Zeiger braucht man dafür nicht. In Java ist es eindeutig definiert was ein Objekt ist und was nicht.

Javas Referenzen == Zeiger.

Konrad Rudolph

rüdiger schrieb:

(Frag zB mal einen Bioinformatiker oder jemand der Datamining betreibt nach den üblichen Datenmengen die er abarbeitet)

Ah, das ist mein Stichwort. – äh, was war die Frage? Ah ja, große Datenmengen. Hmm. Nein, da kann ich nicht helfen.

Tatsächlich ist es so, dass die meisten Algorithmen, wo solche großen Datenmengen relevant wären, eine extrem schlechte Laufzeit haben. Um hier arbeiten zu können, benötigt man eh distributed computing und daher schlägt man sich auch nicht mit so großen Datensätzen herum sondern unterteilt diese in kleine Blöcke.

Klar, Ausnahmen gibt's auch. Z.B. sind Datenbanken wie BLAST grundsätzlich im RAM gecached. Hier braucht man in der Tat so große Datensätze.

D(Event) schrieb:

Ein Array? Ein statisches Array?

Was heißt statisch? Statisch im Sinne von Java-Array-statisch? Ja, wieso nicht? Die Daten werden einmal eingelesen, aus einem Rutsch, und alle weiteren Zugriffe darauf sind lediglich Lesezugriffe, d.h. die Arraygröße verändert sich nicht mehr.

pale dog

rüdiger schrieb:

DEvent schrieb:

Wieso diskutiert ihr überhaupt das man ein Array mit über 4 Gigs haben kann? Wer nimmt den für solch große und vor allem dynamischen Größen ein statisches Array?

Klar gibt es Fälle wo man so etwas braucht. 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
das bringt jedes OS (und jede VM) zum stöhnen.
für sowas gibt's z.b. 'memory mapped files', womit man sich ausschnitte aus riesig fetten dateien in den speicher einblenden kann. viele OS'se können das - und Java kann's natürlich auch: http://java.sun.com/j2se/1.4.2/docs/api/java/nio/MappedByteBuffer.html

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.