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

dot

pale dog schrieb:

okay jungs, ich wusste dass ihr das nicht nicht so hinnehmen würdet
aber jetzt kommt die hammerthese: wer C und Java hat/kann/nutzt braucht kein C++, niemals!
sieht das jemand anders?

ich seh jedenfalls, dass das nicht beantwortet, warum oben von dir genannte punkte zu "diversen nachteilen" bei OOP führen.

DEvent

CStoll schrieb:

@Grogor: In C++ kannst du auch mit Referenzen und Zeigern arbeiten. Aber im Gegensatz zu Java kannst du selber entscheiden, wo du Zeiger verwendest und wo nicht.

Jester schrieb:

CStoll schrieb:

Selbst wenn du der Meinung bist, daß diese Sichtweise konsistent ist, erklärt das noch immer nicht die Unterschiede zwischen Build-in Typen und eigenen Klassen.

Welche Unterschiede denn? Nochmal: Es gibt eingebaute Datentypen und Referenzen. Wo unterscheidet sich da jetzt was?

Technisch unterscheidet sich das vielleicht nicht, aber semantisch - Build-ins stehen für sich selbst, Referenzen für jemand anderes.

Nein, man kann es auch so sehen: Es gibt eine abzählbare Menge von Buildin-Objekten. Die bei Programmstart (oder wann auch immer) erzeugt werden.

int a = 5;
int b = a;
b = b + 5;

Die Referenz "a" zeigt auf das Object "5". Dann zeigt die Referenz b auf das selbe Objekt wie "a", also "5". Dann zeigt die Referenz auf das Objekt 10. Die Referenz a wird aber nicht verändert, sie zeigt immernoch auf das Objekt 5.

Foo a = new Foo();
Foo b = a;
b.add(5);

Die Referenz "a" zeigt auf das Object "Foo_1". Dann zeigt die Referenz b auf das selbe Objekt wie "a", also "Foo_1". Dann verändere ich den Zustand von dem Objekt "Foo_1". Die Referenz a und b wird aber nicht verändert, sie zeigt immernoch auf das Objekt "Foo_1".

(mit "zeigt" meine ich "referenziert")

Somit kriegt man wirklich nie in Java die richtigen Objekte in die Hand, sondern nur Referenzen darauf. Genauso wie bei echten Objekten und wie bei Buildins. Ist das jetzt konsitent genug?

Wer übrigens Operatorüberladungen in Java haben will, da gibt es so ein Projekt, das die Sprache Java bereichert. Ist aber 100% kompatibel zu dem normalen Java, weil die Operator-Aufrufe in normale Methoden-Aufrufe umgewandelt werden.

Übrigens: Wenn man will das eine Methode (add, sub, mul, ...) bei Zahlen-Klassen immer die selbe ist, kann man sich ja eine Klassenhierachie bauen oder ein Interface definieren.

Die Generics sind in Java gut, den sie erfüllen das was man von ihnen wollte: Statische Typsicherheit. Wer auf Perfomance aus ist, der kann die Java-Native-Collection-Lib benutzen. Da gibts die FloatArray, FloatList usw. Und wenn man unbedingt Perfomance braucht, der will auch bestimmt ganz genau definieren mit welchem Datentyp man arbeiten sollte. Also sehe ich dort kein Vorteil von Generalizität. Wenn du einen beliebigen Datentyp hinwirfst, dann kann man deine Micro-Verbesserungen eh vergessen.

Gast++

Im Kreis ich finde wir uns drehen...

Deshalb versuch ich einfach nochmal eine kleine Fallstudie anzuregen:

http://www.c-plusplus.net/forum/viewtopic-var-p-is-1290219.html

Die Erkenntnis dem Programmierer aus dem Tun fliesst zu!

Grüsse

*this

Töss,

was ne scheiß Diskussion, die eh zu keinem Resultat kommt...

Bitte bei 100 Seiten schliessen, damit der dämliche Thread verschwindet!!!

Post 2

Post 3

Post 4

Post 5

Post 6

Post 7

Post 7

Post 8

Post 9

Wer die Schnauze von diesem Thema voll hat, einfach auch mal ne Seite posten

leer

finix

pale dog schrieb:

okay jungs, ich wusste dass ihr das nicht nicht so hinnehmen würdet

Weil dir selber klar war das dein Argument nix taugt?

pale dog schrieb:

aber jetzt kommt die hammerthese: wer C und Java hat/kann/nutzt braucht kein C++, niemals!
sieht das jemand anders?

Hehe, und weiter?
Wer C++ kann braucht weder C noch Java.
Wer Java kann braucht auch kein C.
...

pale dog schrieb:

btw: PHP war ursprünglich auch rein prozedural, wurde dann aber um OO features erweitert - und - was soll ich sagen? es wirkt auf mich genau so zusammengefrickelt wie C++, das dereinst aus C entstanden ist.

PHP war schon immer scheiße. Siehe z.B. http://tnx.nl/php.

CStoll

pale dog schrieb:

dot schrieb:

pale dog schrieb:

hat es in einer OOP-sprache aber diverse nachteile.

würd mich jetzt interessieren welche das sind.

^siehe gregors beitrag^
z.b. unbeabsichtigtes erzeugen von objekten --> das programm läuft zwar wie geplant, aber langsam und speicherintensiv weil ständig unnütze objektkopien erzeugt werden.

Und wo ist das Problem dabei? Wenn ich in C++ eine unbeabsichtigte Kopie entdecke, kann ich sie auch umgehen, indem ich mit Referenzen/Zeigern arbeite - wenn ich in Java eine Objektkopie brauche, muß ich nach komplizierten Workarounds suchen, die noch dazu "besser nicht verwendet" werden sollten. Java ist von C++ ausgegangen und hat alles über Bord geworfen, was sie für "nicht objektorientiert" oder "möglicherweise fehleranfällig" gehalten haben - klar ist die Sprache dadurch sicherer, leichter handhabbar und eventuell sogar besser strukturiert, aber auf keinen Fall mächtiger geworden.

DEvent schrieb:

CStoll schrieb:

@Grogor: In C++ kannst du auch mit Referenzen und Zeigern arbeiten. Aber im Gegensatz zu Java kannst du selber entscheiden, wo du Zeiger verwendest und wo nicht.

Jester schrieb:

CStoll schrieb:

Selbst wenn du der Meinung bist, daß diese Sichtweise konsistent ist, erklärt das noch immer nicht die Unterschiede zwischen Build-in Typen und eigenen Klassen.

Welche Unterschiede denn? Nochmal: Es gibt eingebaute Datentypen und Referenzen. Wo unterscheidet sich da jetzt was?

Technisch unterscheidet sich das vielleicht nicht, aber semantisch - Build-ins stehen für sich selbst, Referenzen für jemand anderes.

Nein, man kann es auch so sehen: Es gibt eine abzählbare Menge von Buildin-Objekten. Die bei Programmstart (oder wann auch immer) erzeugt werden.
int a = 5;
int b = a;
b = b + 5;
Die Referenz "a" zeigt auf das Object "5". Dann zeigt die Referenz b auf das selbe Objekt wie "a", also "5". Dann zeigt die Referenz auf das Objekt 10. Die Referenz a wird aber nicht verändert, sie zeigt immernoch auf das Objekt 5.
Foo a = new Foo();
Foo b = a;
b.add(5);
Die Referenz "a" zeigt auf das Object "Foo_1". Dann zeigt die Referenz b auf das selbe Objekt wie "a", also "Foo_1". Dann verändere ich den Zustand von dem Objekt "Foo_1". Die Referenz a und b wird aber nicht verändert, sie zeigt immernoch auf das Objekt "Foo_1".

(mit "zeigt" meine ich "referenziert")

Somit kriegt man wirklich nie in Java die richtigen Objekte in die Hand, sondern nur Referenzen darauf. Genauso wie bei echten Objekten und wie bei Buildins. Ist das jetzt konsitent genug?

OK, dann ist das Problem vielleicht im Verständnis. Das Objekt "5" wird sich nie ändern und immer den Wert 5 repräsentieren, das Objekt Foo_1 ändert sich zur Laufzeit. Und diese Seiteneffekte (ein Aufruf von b.Add() ändert das Verhalten/den Zustand des Objekts, auf das a referenziert) stören mich - besonders weil ich nicht kontrollieren kann, wo sich b befindet und wann eine seiner Methoden aufgerufen werden könnte. (oder gibt es in Java eine Entsprechung zu 'const T&'?)

Übrigens: Wenn man will das eine Methode (add, sub, mul, ...) bei Zahlen-Klassen immer die selbe ist, kann man sich ja eine Klassenhierachie bauen oder ein Interface definieren.

Ja, ich kann ein Interface INumber erstellen, das mein Benennungskonzept für Methoden darstellt. Aber was mache ich, wenn ich eine fremde Zahlenklasse finde, die zwar genau meinen Anforderungen im Projekt entspricht, aber dummerweise keine Ahnung von INumber hat?

@Töss: Und du meinst wirklich, dein "Beitrag" hilft irgendeiner Seite?

tntnet

pale dog schrieb:

okay jungs, ich wusste dass ihr das nicht nicht so hinnehmen würdet
aber jetzt kommt die hammerthese: wer C und Java hat/kann/nutzt braucht kein C++, niemals!
sieht das jemand anders?

Das sehe ich genauso. Echt klasse Aussage . Du hast absolut recht. Wer einen Opel hat, braucht keinen VW, niemals! Warum sollte ich VW fahren, wenn ich einen Opel habe. Und wenn ich einen VW habe, brauche ich keinen Opel.

Interessanterweise sagst Du aber auch, daß Java nicht ausreicht. Du brauchst noch C dazu. Bei C++ sieht das anders aus. C++ kann alles. Wer C++ hat/kann/nutzt braucht nichts anderes.

Übrigens für diejenigen, die diesen Thread uninteressant finden: einfach ignorieren. Ich habe das Gefühl, hier gibt es ausreichend Leute, die diesen Thread lieben, wie keinen anderen zuvor.

finix

CStoll schrieb:

OK, dann ist das Problem vielleicht im Verständnis. Das Objekt "5" wird sich nie ändern und immer den Wert 5 repräsentieren, das Objekt Foo_1 ändert sich zur Laufzeit. Und diese Seiteneffekte (ein Aufruf von b.Add() ändert das Verhalten/den Zustand des Objekts, auf das a referenziert) stören mich - besonders weil ich nicht kontrollieren kann, wo sich b befindet und wann eine seiner Methoden aufgerufen werden könnte.

Sein Beispiel wäre mit

ImmutableFoo a = new ImmutableFoo();
ImmutableFoo b = a;
b = b.add(5); // _wirklich_ analog zu 'b = b + 5'

vielleicht noch ein klein wenig geschickter ausgefallen.

CStoll schrieb:

(oder gibt es in Java eine Entsprechung zu 'const T&'?)

Nope.

CStoll schrieb:

@Töss: Und du meinst wirklich, dein "Beitrag" hilft irgendeiner Seite?

Kannst du die nicht einfach löschen?

CStoll

finix schrieb:

CStoll schrieb:

OK, dann ist das Problem vielleicht im Verständnis. Das Objekt "5" wird sich nie ändern und immer den Wert 5 repräsentieren, das Objekt Foo_1 ändert sich zur Laufzeit. Und diese Seiteneffekte (ein Aufruf von b.Add() ändert das Verhalten/den Zustand des Objekts, auf das a referenziert) stören mich - besonders weil ich nicht kontrollieren kann, wo sich b befindet und wann eine seiner Methoden aufgerufen werden könnte.

Sein Beispiel wäre mit
ImmutableFoo a = new ImmutableFoo();
ImmutableFoo b = a;
b = b.add(5); // _wirklich_ analog zu 'b = b + 5'
vielleicht noch ein klein wenig geschickter ausgefallen.

Ja, aber dann müsste die Methode add() ja wieder eine Objektkopie anlegen (und wie mir weiter oben erklärt wurde, ist das nicht wirklich trivial für eigene Klassen)

CStoll schrieb:

(oder gibt es in Java eine Entsprechung zu 'const T&'?)

Nope.

Und wieso nicht? War Const Correctness zu unsicher oder nicht OO-like genug, um in Java Einzug zu halten?
(und wie kann ich in Java verhindern, daß eine Fremdfunktion meine Objekte ändert?)

CStoll schrieb:

@Töss: Und du meinst wirklich, dein "Beitrag" hilft irgendeiner Seite?

Kannst du die nicht einfach löschen?

Leider nein - ich bin zwar Moderator, aber nicht in diesem Board.