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

[Konrad Rudolph]

pale dog schrieb:

aber warum sollte man diese technik nutzen sollen, ausser man will solche haarsträubenden codes basteln wie in deinem beispiel da oben?

Weil sich über die Jahre gezeigt hat, dass das Zeiger-Konzept eine sehr simple und mächtige Abstraktion ist, um mit der Maschine zu kommunizieren. Sicher, wenn man nicht hardwarenahe programmieren will, braucht man die Spezialisierung "Zeiger" nicht unbedingt. Das Über-Konzept "Iterator" wäre aber trotzdem praktisch.

[CStoll]

pale dog schrieb:

CStoll schrieb:

pale dog schrieb:

CStoll schrieb:

Aber durch diese Festlegungen versperrst du dir den Weg für zukünftige Entwicklungen. C++ Compiler mit 128-Bit int's sind kein Problem, Java Compiler werden auch in Hundert Jahren noch mit 32-Bit hantieren.
=> der Punkt geht ebenfalls an C++.

jein
in 100 jahren wird der heutige, 32-bittige Java datentyp (int) zwar gleich bleiben, aber dafür können zusätzliche, breitere datentypen eingeführt werden, wenn bedarf bestehen sollte (deren repräsentation sich übrigens auch niemals ändern wird).
sorry, den punkt müssen wir C++ leider wieder abziehen.

Aber um diese breiteren Datentypen nutzen zu können, müsstest du alle deine Programme von Hand anpassen - da wünsche ich dir viel Spaß bei dem Versuch, in einem größeren Projekt alle Vorkommen von 'int' zu finden und zu entscheiden, welcher größere Datentyp für diese Werte nun ausreichend ist. Meine C++ Projekte muß ich nur neu compilieren, um die neue Architektur nutzen zu können.

warum sollte ich in einem bereits funktionierenden programm alle 'ints' ändern wollen
das wäre doch blödsinn.

Vielleicht weil sich mit dem neuen System die Anforderungen an das Programm geändert haben und die 32 Bit von int plötzlich doch nicht mehr ausreichen

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

Klar kannst du gerne vergessen, daß du mit Pointern arbeitest. Aber deswegen sind sie trotzdem da (mit fast allen damit verbundenen Problemen, aber ohne echte Vorteile gegenüber C++ Zeigern).

aber warum sollte man diese technik nutzen sollen, ausser man will solche haarsträubenden codes basteln wie in deinem beispiel da oben?
man macht einfach:

int i = 0x010204;
i |= 0x102000

und gut is'

Weil man's kann (*scnr*) (und ob dein Code wirklich die selbe Wirkung hat wie Simon's, ist auch offen)

[Simon2]

pale dog schrieb:

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

Oha, sollte man doch auf jeden Fall tun. Schließlich reicht man die Zeiger doch überall rum. Rufe ich eine Funktion auf und übergebe ihr einen Parameter, muss ich wissen, dass ich ihr damit einen Zeiger (auf mein Objekt) gebe; liefere ich in einem getter ein Attribut zurück, muss ich daran denken, das ich einen Zeiger zurückgeben; setze ich eine Variable auf 0, muss ich wissen, ob ich damit einen Zeiger "NULLe" oder einen Wert (int&Co); Zeiger werden rumgecastet (nicht Objekte); ....

Man hantiert doch immer mit Zeigern rum in Java (außer eben int&Co) - wie sollte man vergessen können, dass es welche sind ?

Gruß,

Simon2.

[templäd]

Ich würde die Java zeiger auch eher mit den C++ Referenzen Vergleichen.
Leider können Referenzen in beiden Sprachen null sein :(.
Ich kann mich nur schwer damit anfreunden, dass man auf null referenzieren kann.

[Konrad Rudolph]

templäd schrieb:

Ich würde die Java zeiger auch eher mit den C++ Referenzen Vergleichen.
Leider können Referenzen in beiden Sprachen null sein :(.
Ich kann mich nur schwer damit anfreunden, dass man auf null referenzieren kann.

Da hast Du aber ein Problem, denn ohne das Konzept von Nullreferenzen wären die Java-Referenzen nun wirklich nutzlos. Man könnte ja nicht einmal eine verkettete Liste damit darstellen, denn aufgrund Deiner Einschränkung wäre kein Ende möglich.

[LordJaxom]

templäd schrieb:

Ich würde die Java zeiger auch eher mit den C++ Referenzen Vergleichen.

Sehe ich nicht so, denn man kann C++-Referenzen
a) nicht verbiegen
b) nicht auf Null zeigen lassen
c) nicht mit Null vergleichen
d) nicht daraufhin vergleichen, ob dasselbe Objekt referenziert wird
Alles das kann man mit Zeigern.

Damit meine ich den direkten Weg, mir ist klar dass man fast all dies realisieren kann, indem man die Referenz zu einem Zeiger degradiert. Folgendes gilt also nicht

int& refa = *(new int);
int& refb = *static_cast<int*>(0); // b
if (&refb == 0) // c
if (&refa == &refb) // d

[Baracke_]

Warum kein Ende möglich? Könnte man nicht auf sich selbst zeigen und das als Ende markieren, anstatt dem mehr oder minder eingebürgerten Null-Zeiger?

Gruß Baracke

[Konrad Rudolph]

Baracke_ schrieb:

Warum kein Ende möglich? Könnte man nicht auf sich selbst zeigen und das als Ende markieren, anstatt dem mehr oder minder eingebürgerten Null-Zeiger?

Klar, das geht natürlich. Nächste Frage: Leere Liste? Ein "empty"-Platzhalterelement? Naa ja.

[Phoemuex]

Konrad Rudolph schrieb:

Baracke_ schrieb:

Warum kein Ende möglich? Könnte man nicht auf sich selbst zeigen und das als Ende markieren, anstatt dem mehr oder minder eingebürgerten Null-Zeiger?

Klar, das geht natürlich. Nächste Frage: Leere Liste? Ein "empty"-Platzhalterelement? Naa ja.

Doch, das ist gar keine schlechte Idee, dass man in einer leeren Liste ein Dummy-Element hat und das letze Element in der Liste immer auf den Anfang der Liste zeigt. Damit kann man das ganze nämlich effizienter implementieren, Jester hat darüber auf dem Forentreffen einen Vortrag gehalten

Felix

P.S.: Ich finde auch, dass man sich schon klar sein sollte, dass in Java im Wesentlichen Zeiger (oder - wenn man so will - änderbare Referenzen) verwendet werden. 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?

[pale dog]

CStoll schrieb:

Vielleicht weil sich mit dem neuen System die Anforderungen an das Programm geändert haben und die 32 Bit von int plötzlich doch nicht mehr ausreichen

dafür, dass das programm auf sich auf allen systemen gleich verhält, sorgt die VM.
...und wenn 32 bits nicht reichen, nimmt man einen breiteren datentyp.
wie das die 'V'M im endeffekt mit der realen 'M' aushandelt, sollte im normalfall dem Java-coder kein kopfzerbrechen bereiten.

CStoll schrieb:

und ob dein Code wirklich die selbe Wirkung hat wie Simon's, ist auch offen

naja, Simons code mit dem int* nach char* -gecaste ist architekturabhängig. sowas ist meistens kein vorteil.

Simon2 schrieb:

Man hantiert doch immer mit Zeigern rum in Java (außer eben int&Co) - wie sollte man vergessen können, dass es welche sind ?

erzähl das mal einem nur-java programmierer. diese leute haben meistens eine ziemliche 'high-level' sichtweise und wissen erstmal gar nicht was du von denen willst.

templäd schrieb:

Ich würde die Java zeiger auch eher mit den C++ Referenzen Vergleichen.

eigentlich nicht. in C++ sind referenzen compile-time aliase, in Java sind es 'richtige' variablen.

[Baracke_]

Ich geb ja zu das es nicht grad ideal wäre, jedoch wollte auch nur das absolute aus deiner Ausage entfernen

Anzumerken ist noch das man in Java mehr oder weniger einen ""empty"-Platzhalterelement" hat und zwar 'null'. In C++ gibt es sowas nicht für Zeiger, da ist es die einfache 0 und kann schon mal zu (Cast)Fehlern führen.

Wie auch immer ich halte die Diskussion was ist besser was ist schlechter ala 20 zu 15 für Java für sinnlos. Da es 2 unterschiedliche paar Schuhe sind und je nachdem in welchen Umfeld man sich bewegt trägt sich der eine mal besser, mal der andere.

Und wie immer ist es auch da so das der Träger seine Lieblingschuhe hat.....
Oder wie ein Forummitglied aus einem anderem Forum mal sage:
"Saying Java is nice because it works on all OS is like saying anal sex is nice because it works on all genders."

Gruß Baracke

[CStoll]

pale dog schrieb:

CStoll schrieb:

Vielleicht weil sich mit dem neuen System die Anforderungen an das Programm geändert haben und die 32 Bit von int plötzlich doch nicht mehr ausreichen

dafür, dass das programm auf sich auf allen systemen gleich verhält, sorgt die VM.
...und wenn 32 bits nicht reichen, nimmt man einen breiteren datentyp.

Und wie willst du dein Programm auf einen breiteren Datentyp umstellen, ohne jedes Vorkommen von 'int' zu suchen und ersetzen?

Simon2 schrieb:

Man hantiert doch immer mit Zeigern rum in Java (außer eben int&Co) - wie sollte man vergessen können, dass es welche sind ?

erzähl das mal einem nur-java programmierer. diese leute haben meistens eine ziemliche 'high-level' sichtweise und wissen erstmal gar nicht was du von denen willst.

Und das soll dann ein Problem für einen C++'ler darstellen?

templäd schrieb:

Ich würde die Java zeiger auch eher mit den C++ Referenzen Vergleichen.

eigentlich nicht. in C++ sind referenzen compile-time aliase, in Java sind es 'richtige' variablen.

Nicht wirklich Ich würde sie eher auf eine Ebene mit C++ Smart-Pointern stellen (wenn es denn überhaupt eine exakte Entsprechung dazu in C++ geben sollte).

[pale dog]

Baracke_ schrieb:

Wie auch immer ich halte die Diskussion was ist besser was ist schlechter ala 20 zu 15 für Java für sinnlos.

sinnlos ja, es macht aber spass

Baracke_ schrieb:

"Saying Java is nice because it works on all OS is like saying anal sex is nice because it works on all genders."

ach, das ist doch nur polemik von neidern
über viele programmiersprachen gibt es solche lästersprüche...

[Konrad Rudolph]

Phoemuex schrieb:

Klar, das geht natürlich. Nächste Frage: Leere Liste? Ein "empty"-Platzhalterelement? Naa ja.

Doch, das ist gar keine schlechte Idee, […][/quote]
Okay, überzeugt. Mir fällt gerade ein, dass ich mal ne Liste genauso implementiert habe.

Baracke_ schrieb:

Anzumerken ist noch das man in Java mehr oder weniger einen ""empty"-Platzhalterelement" hat und zwar 'null'. In C++ gibt es sowas nicht für Zeiger

Na ja. Prinzipiell übernimmt '0' doch genau diese Aufgabe. In C++0x dann halt 'nullptr'.

[pale dog]

CStoll schrieb:

pale dog schrieb:

CStoll schrieb:

Vielleicht weil sich mit dem neuen System die Anforderungen an das Programm geändert haben und die 32 Bit von int plötzlich doch nicht mehr ausreichen

dafür, dass das programm auf sich auf allen systemen gleich verhält, sorgt die VM.
...und wenn 32 bits nicht reichen, nimmt man einen breiteren datentyp.

Und wie willst du dein Programm auf einen breiteren Datentyp umstellen, ohne jedes Vorkommen von 'int' zu suchen und ersetzen?

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

[tntnet]

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.

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.

[Simon2]

pale dog schrieb:

...
naja, Simons code mit dem int* nach char* -gecaste ist architekturabhängig. sowas ist meistens kein vorteil. ...

Gut - damit bist Du auf der Schiene "Wurde rausgeworfen weil schlecht" ... und nicht mehr auf "gibt's doch !".
IMO ist es eine Technik, die man in bestimmten Umfeldern (wie 1000mal gesagt: HW-nah und damit IMMER plattformabhängig) sinnvoll einsetzen KANN (nicht "muss") - und die Java eben entfernt hat (weil sie auf ein anderes Umfeld abzielt).
Wie schon gesagt: Mehr will ich gar nicht darlegen.

pale dog schrieb:

...

Simon2 schrieb:

Man hantiert doch immer mit Zeigern rum in Java (außer eben int&Co) - wie sollte man vergessen können, dass es welche sind ?

erzähl das mal einem nur-java programmierer. diese leute haben meistens eine ziemliche 'high-level' sichtweise und wissen erstmal gar nicht was du von denen willst....

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.

Gruß,

Simon2.

[Baracke_]

Baracke_ schrieb:

...
Anzumerken ist noch das man in Java mehr oder weniger einen ""empty"-Platzhalterelement" hat und zwar 'null'. In C++ gibt es sowas nicht für Zeiger, da ist es die einfache 0 und kann schon mal zu (Cast)Fehlern führen.
...

Konrad Rudolph schrieb:

Baracke_ schrieb:

Anzumerken ist noch das man in Java mehr oder weniger einen ""empty"-Platzhalterelement" hat und zwar 'null'. In C++ gibt es sowas nicht für Zeiger

Na ja. Prinzipiell übernimmt '0' doch genau diese Aufgabe. In C++0x dann halt 'nullptr'.

Da muss ich dir recht geben, 'nullptr' hab ich nicht erwähnt

Gruß Baracke

[pale dog]

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.

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.
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

btw: manchmal frage ich mich, wieso ich als C-coder weniger schwierigkeiten mit der 'Java-denke' habe, als so mancher C++ programmierer?

[CStoll]

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 hast du (nur für zukünfitge Entwicklungen) auch einen 128-Bit Datentyp für Java in der Hinterhand?

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.
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

Eben nicht. Bei einem XYZ hast du zwei Referenzen, die auf das selbe Objekt zeigen (und Methodenaufrufe auf MyYXZ machen sich auch bei MyXYZ2 bemerkbar), wenn du es durch int ersetzt, hast du zwei unabhängige Variablen.

(und daß es in Java nicht gerade trivial ist, eine unabhängige Kopie eines Objektes anzulegen, hatten wir schon)