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

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

  • C

    rüdiger schrieb:

    pale dog schrieb:

    btw, damit vm-sprachen hierbei nicht ganz alt aussehen:
    so'ne vm hat die möglichkeit zur laufzeit den code zu optimieren (jit-compiler) und ihre 'virtuellen maschinenparameter' an die umgebung anzupassen. es wäre schon denkbar, dass in manchen situationen ein vm-programm scheller läuft, als eine statische 'exe'.

    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)

    Und was die Entwicklung der VM angeht: Java definiert afair exakte Größen für die verwendeten Datentypen - unabhängig von den tatsächlichen Möglichkeiten des Systems. Im C++ Standard sind legiglich Mindestgrößen definiert (und es ist durchaus erlaubt, daß irgendein zukünfitger Compiler 16-Bit-char's festlegt).

    0
  • S

    DEvent schrieb:

    ...

    Äh - ja, wo ist jetzt der Unterschied zu dem normalen Umgang mit Source ? Wo ist da die spezifische Reflectionnutzung ?
    Was Du da beschreibst, mache ich genauso ... eben mit C++, aber das ginge mit Fortran, COBOL, ASM, .... genauso.

    Geht Reflection in C++ genauso wie in Java? Also kann man (nur) kompilierten Code nehmen und daraus auf alle Eigenschaften der Klasse zugreifen?...

    Ich habe nie geschrieben, dass "Reflection" (eine spezielle JavaTechnik) in C++ genauso ginge !
    Es geht mir darum, welche Fachlichkeit Gregor damit abbilden möchte ... und was immer er dazu bislang gesagt hat (außer dem ominösen Verweis auf sein laufendes Projekt), erledigt mein Compiler (Sprache nahezu beliebig) genauso - wenn nicht gar besser.

    Gruß,

    Simon2.

    0
  • P

    CStoll schrieb:

    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)

    ja, Java arbeitet intern sogar mit pointern auf pointer... 🙂
    für den benutzer ist dies alles aber nicht sichtbar, d.h. er kann sich keine 'dangling and wild' pointers einfangen oder sich mit pointerarithmetik verheddern.
    wieder ein punkt für Java 👍

    CStoll schrieb:

    Und was die Entwicklung der VM angeht: Java definiert afair exakte Größen für die verwendeten Datentypen - unabhängig von den tatsächlichen Möglichkeiten des Systems. Im C++ Standard sind legiglich Mindestgrößen definiert (und es ist durchaus erlaubt, daß irgendein zukünfitger Compiler 16-Bit-char's festlegt).

    ja, das ist in Java festgelegt, ebenso wie die byte order. du weisst ja selbst, welche probleme unterschiedliche byte-order und plattformabhängige grössen von datentypen so mit sich bringen.
    ...und noch ein punkt für Java 👍

    wie ist das scoring zur zeit? 15:20 für Java? 😉

    0
  • S

    pale dog schrieb:

    CStoll schrieb:

    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)

    ja, Java arbeitet intern sogar mit pointern auf pointer... 🙂
    für den benutzer ist dies alles aber nicht sichtbar, d.h. er kann sich keine 'dangling and wild' pointers einfangen oder sich mit pointerarithmetik verheddern.
    ...

    Ach, wenn doch Sun und die anderen Java-Protagonisten das doch von Vorneherein so gut ausgedrückt hätten !! 😋
    Die Verkürzung "no pointers" bringt einfach aufs falsche Gleis.

    Gruß,

    Simon2.

    Übrigens: C++ zwingt niemanden dazu, Pointerarithmetik anzuwenden - ich selbst habe sie noch nie verwendet (außer zu Lernzwecken). Ich kann schwerlich einen Punkt für Java nur dafür vergeben, dass sie einfach eine Technik verwirft 😃 Sonst würde ich einfach meinen eigenen Java-Nachkommen entwerfen, in dem ich 2 Features rauswerfe, die in Java von Angängern zu Schwierigkeiten geführt haben - und hätte plötzlich eine "besser Sprache". 😉

    0
  • C

    pale dog schrieb:

    CStoll schrieb:

    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)

    ja, Java arbeitet intern sogar mit pointern auf pointer... 🙂
    für den benutzer ist dies alles aber nicht sichtbar, d.h. er kann sich keine 'dangling and wild' pointers einfangen oder sich mit pointerarithmetik verheddern.
    wieder ein punkt für Java 👍

    Aber dafür kann man sich ganz schnell verheddern, wenn man das Pointer-Konzept nicht verstanden hat (wenn ich in C++ ein Objekt an eine Funktion übergebe, kann ich ganz genau kontrollieren, wie der Bezug zwischen Argument und Parameter aussieht - in Java ist die Übergabekonvention fest vorgegeben.
    => Wenn du es schon so willst, Punkt für C++.

    (und du hast mal wieder nur die Hälfte von meinem Beitrag gelesen - der bezog sich vor allem auf das Optimierungspotential aus den (angeblich) fehlenden Pointern)

    CStoll schrieb:

    Und was die Entwicklung der VM angeht: Java definiert afair exakte Größen für die verwendeten Datentypen - unabhängig von den tatsächlichen Möglichkeiten des Systems. Im C++ Standard sind legiglich Mindestgrößen definiert (und es ist durchaus erlaubt, daß irgendein zukünfitger Compiler 16-Bit-char's festlegt).

    ja, das ist in Java festgelegt, ebenso wie die byte order. du weisst ja selbst, welche probleme unterschiedliche byte-order und plattformabhängige grössen von datentypen so mit sich bringen.
    ...und noch ein punkt für Java 👍

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

    wie ist das scoring zur zeit? 15:20 für Java? 😉

    Keine Ahnung, ich hab' da nicht mitgezählt.
    (aber wenn ich raten würde, dürfte auf lange Sicht ein unentschieden herauskommen)

    0
  • P

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

    0
  • B

    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.

    0
  • S

    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.

    0
  • K

    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.

    0
  • P

    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.

    0
  • C

    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.

    0
  • S

    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.

    0
  • P

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

    0
  • K

    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.

    0
  • C

    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)

    0
  • S

    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.

    0
  • ?

    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.

    0
  • K

    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.

    0
  • L

    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
    0
  • ?

    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

    0
Anmelden zum Antworten