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

[pale dog]

Simon2 schrieb:

Ich kann schwerlich einen Punkt für Java nur dafür vergeben, dass sie einfach eine Technik verwirft

die technik wird ja nicht verworfen sondern abstrahiert bzw. 'gekapselt'.
daran dürften OOP-fans doch nichts auszusetzen haben...

[Bashar]

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.

[Simon2]

pale dog schrieb:

Simon2 schrieb:

Ich kann schwerlich einen Punkt für Java nur dafür vergeben, dass sie einfach eine Technik verwirft

die technik wird ja nicht verworfen sondern abstrahiert bzw. 'gekapselt'.
daran dürften OOP-fans doch nichts auszusetzen haben...

Wie jetzt ? Doch Pointerarithmetik in Java ?

unsigned int i = 0x010204;
unsigned char* p = (unsigned char*) &i;
*p |= 0x10;
*(p+1) |= 0x20;

Show me ...

Gruß,

Simon2.

[Konrad Rudolph]

pale dog schrieb:

Simon2 schrieb:

Ich kann schwerlich einen Punkt für Java nur dafür vergeben, dass sie einfach eine Technik verwirft

die technik wird ja nicht verworfen sondern abstrahiert bzw. 'gekapselt'.
daran dürften OOP-fans doch nichts auszusetzen haben...

Ich weiß nicht, ich weiß nicht. An sich spricht natürlich nichts gegen eine Abstraktion von Zeigern. Aber IMHO macht es Java falsch und andere Sprachen, z.B. Eiffel machen es richtig. Java hat eben *keine* allgemeine Zeigerabstraktion sondern es verwendet unter der Haube Zeiger, um andere Konzepte zu implementieren. Was mir fehlt, ist eine Zeiger-Schnittstelle, mit der ich z.B. auf das erste Element in einem 'int'-Array (*nicht 'Integer'!) zeigen kann und zum nächsten Element springen kann. Cs Stärke ist, dass es sowas eingeführt hat. C++s Stärke ist, dass dieses Konzept abstrahiert und verbessert wurde ('is' sei ein 'int'-Array):

// C:
int* pi = &is[0];
*++pi;

// C++:
vector::iterator pi = is.begin();
*++pi;

Das Iterator-Konzept von Java reicht da nicht heran.

[pale dog]

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.

Simon2 schrieb:

Wie jetzt ? Doch Pointerarithmetik in Java ?

unsigned int i = 0x010204;
unsigned char* p = (unsigned char*) &i;
*p |= 0x10;
*(p+1) |= 0x20;

Show me ...

nein, so doch nicht
die pointer sind versteckt in Java.

[CStoll]

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.

Simon2 schrieb:

Wie jetzt ? Doch Pointerarithmetik in Java ?

unsigned int i = 0x010204;
unsigned char* p = (unsigned char*) &i;
*p |= 0x10;
*(p+1) |= 0x20;

Show me ...

nein, so doch nicht
die pointer sind versteckt in Java.

[/quote]Und das ist das Problem Die Pointer sind zwar da (und man muß sich immer wieder vor Augen führen, daß man in Wirklichkeit "nur" Zeiger in der Hand hält), aber wirklich nutzen kann man sie nicht.

[Simon2]

pale dog schrieb:

...

Simon2 schrieb:

Wie jetzt ? Doch Pointerarithmetik in Java ?

unsigned int i = 0x010204;
unsigned char* p = (unsigned char*) &i;
*p |= 0x10;
*(p+1) |= 0x20;

Show me ...

nein, so doch nicht
die pointer sind versteckt in Java.

Ergo: Dem Programmierer steht diese Technik nicht zur Verfügung => Java hat diese Technik "verworfen". Mehr habe ich nicht behauptet.
Andernfalls könnte man Fortran auch als OO-Sprache bezeichnen (die eben "OO kapselt"), wenn der Compiler in OO geschrieben ist.
Blöder als das finde ich dagegen die (schon von Konrad angeführte) Sonderrolle von int&Co (und das Fehlen von "Objektsemantik") ... aber das haben wir schon in einem anderen Thread gehabt.
Das strenge Definieren der Wertebereiche (und der internen Repräsentation) finde ich dagegen großartig ! Da man sich aber damit Optimierungspotential verschenkt, hätte ich mir einfach beides gewünscht: Datentypen, deren Repräsentation festgelegt ist und solche, die Plattformspezifika zulassen (für HW-nahe Geschichten) - vielleicht sogar einen definierten Übergang zwischen beiden.

Gruß,

Simon2.

[pale dog]

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.

CStoll schrieb:

pale dog schrieb:

Simon2 schrieb:

Wie jetzt ? Doch Pointerarithmetik in Java ?

unsigned int i = 0x010204;
unsigned char* p = (unsigned char*) &i;
*p |= 0x10;
*(p+1) |= 0x20;

Show me ...

nein, so doch nicht
die pointer sind versteckt in Java.

Und das ist das Problem Die Pointer sind zwar da (und man muß sich immer wieder vor Augen führen, daß man in Wirklichkeit "nur" Zeiger in der Hand hält)...

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

Simon2 schrieb:

pale dog schrieb:

...

Simon2 schrieb:

Wie jetzt ? Doch Pointerarithmetik in Java ?

unsigned int i = 0x010204;
unsigned char* p = (unsigned char*) &i;
*p |= 0x10;
*(p+1) |= 0x20;

Show me ...

nein, so doch nicht
die pointer sind versteckt in Java.

Ergo: Dem Programmierer steht diese Technik nicht zur Verfügung => Java hat diese Technik "verworfen".

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'

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