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

Simon2

pale dog schrieb:

...

Simon2 schrieb:
Phoemuex schrieb:
...Sonst versteht man doch nicht, dass man hier nur ein einziges Objekt hat:
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?
Hat es IMO schön auf den Puinkt gebracht - und hier denken ganz bestimmt auch "nur-java-programmierer" daran.
nö, für Java programmierer stellt sich das wie folgt dar:
XYZ myXYZ = new XYZ; // objekt wird erzeugt und ein verweis darauf in der referenz myXYZ gespeichert.
...

Eben: Er muss wissen, dass er eine "Referenz" (=Zeiger) in der Hand hat.
Auch hier: Anderes habe ich nicht behauptet - Du schon:

pale dog schrieb:

...
nein, warum sollte man im entfernstesten an zeiger denken, wenn man mit Java programmiert? ...

Antwort: Damit man oben genannten (und von Dir erläuterten) Zusammenhang korrekt versteht.

Zeiger, Zeiger überall .... (außer bei int&Co)

pale dog schrieb:

...
nö, für Java programmierer stellt sich das wie folgt dar:

XYZ myXYZ = new XYZ; // objekt wird erzeugt und ein verweis darauf in der referenz myXYZ gespeichert.
XYZ myXYZ2 = myXYZ;  // eine zweite referenz wird angelegt und der inhalt der ersten referenz dort hineinkopiert.
                     // niemand denkt hierbei an die erzeugeung eines neuen objekts!!!

analog dazu das selbe mit dem 'int', nix unterschied
...

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.

Gruß,

Simon2.

pale dog

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.

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.

Simon2 schrieb:

Kann man mögen/konsistent finden oder nicht.

ich finde es logisch und leicht verständlich.
...und deshalb ist es mir auch sympathisch

btw: aber ich verspreche euch - irgendwann guck' ich mir bestimmt mal python an.

Simon2

pale dog schrieb:

...

Simon2 schrieb:

Kann man mögen/konsistent finden oder nicht.

ich finde es logisch und leicht verständlich.
...und deshalb ist es mir auch sympathisch ..

Tja, ich eben nicht.
Ich finde an C++ eben schöner, dass sich semantisch Variablen überhaupt nicht unterscheiden (sprich: Man hat eben einfach einen "Typen" egal, was sich dahinter verbirgt) und man eben neben der "Zeigersemantik" noch die Objektsemantik haben kann. Es scheint mir konsistenter, die Semantik nicht implizit vom Inhalt abhängig zu machen, sondern durch die Varaiblendeklaration bestimmen zu können.

Aber das ist definitv Geschmackssache - beide Sprachen sind "volksbankorientert", aber mit unterschiedlicher Betonung:
+ C++: "Wir machen den Weg frei !"
+ Java: "Wir machen den Weg frei !"

Gruß,

Simon2.

pale dog

Simon2 schrieb:

+ C++: "Wir machen den Weg frei !"

'frei' mag ja stimmen, aber der weg führt durch ein labyrinth mit vielen fallgruben und sackgassen.

Gast++

Simon2 schrieb:

+ Java: "Wir machen den Weg frei !"

Das finde ich einfach genial antizipiert!
Watzlawick ist doch aus dem Sprachgebrauch schwer wegzudenken...

Um Java-Consultants entsprechend zu beschreiben:
"Nur sie (also wiedermal "DIE") kennen alle den Weg !"

Grüsse

*this

Gast++

pale dog schrieb:

Simon2 schrieb:

+ C++: "Wir machen den Weg frei !"

'frei' mag ja stimmen, aber der weg führt durch ein labyrinth mit vielen fallgruben und sackgassen.

Aber er erfüllt die Mindestanforderung an "Weg" in dem Kontext, er führt hindurch!

btw: aber ich verspreche euch - irgendwann guck' ich mir bestimmt mal python an.

Guckst Du hier: http://www.python.org/doc/essays/
Essays vom Python-Erfinder Giudo van Rossum himself; man beachte "Metaklassen"!
Sonst kenn ich das nur aus Smalltalk.

G

darthdespotism

pale dog schrieb:

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.

naja, unter Java könnte man 'long' als index nehmen, der war schon immer 64 bits breit
aber allgemein halte ich es für keine gute idee, high-level programme von den beschränkungen der hardware abhängig zu machen. wenn du ein C++ programm codest, weisst du ja auch nicht, ob der benutzer nur 1MB oder 100GB RAM hat. das regelt das memory management des OS für dich.
...und wenn man wirklich mit riesigen datenmengen hantiert, wäre es vielleicht besser, eine art DBMS wie berkeley-db o.ä. zu bemühen.

Erstensmal:
Mein Informatik - Lehrer (wir machen da leider Java) meinte dass nur int als Arrayindex zulässig ist.

Und dann ist natürlich immer noch das Problem dass 64bit Arritmetik auf 32bit Systemen unvergleichbar langsamer ist. Und das sollte man auch mit Java spüren.

rüdiger

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.

Bashar schrieb:

CStoll schrieb:

Andererseits kann man nicht so viel Zeit für die Optimierung verwenden, da man ja alles jit machen muss. Aber der Vorteil bei der Optimierung den Java gegenüber C++ hat sind einfach: Keine Pointer. So kann man Aliasing-Probleme etc direkt ausschließen und den Code besser optimieren. Das gilt natürlich für alle Sprachen die keine Pointer haben. Daher ist Fortran zB immer noch sehr beliebt für Berechnungen.

Klar hat Java Pointer, es versteckt sie nur recht gut (genauer gesagt, hantierst du in Java fast nur mit Pointern, auch wenn sie dort als "Referenz" bezeichnet werden und nicht durch ein explizites * gekennzeichnet werden)

Ich glaube rüdiger meinte Pointer auf primitive Typen. Bei Objekten bleibt das Aliasing-Problem natürlich bestehen, aber da ist das meistens auch nicht so wichtig.

Wobei man beim "Just-in-Time" kompilieren ja sogar Aliasing mit Pointern in den Griff bekommt, da man ja alle existierenden Pointer kennt. Aber bei Objekten ist das ja, wie du schon gesagt hast, nicht so wichtig.

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')

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

Wie ich schon vor ein paar Seiten sagte: Man muss bei Java generell wissen, das Typen und Klassen bzw. Variablen und Objekte etwas vollkommen verschiedenes sind.

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.