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

[Töss]

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

[Schnauze Voll]

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.

[Simon2]

pale dog schrieb:

...
aber jetzt kommt die hammerthese: wer C und Java hat/kann/nutzt braucht kein C++, niemals!...

Meine Hammerthese: Wer C++ hat/kann/nutzt, braucht kein Java, niemals (und C bekommt er quasi "geschenkt" - er braucht sich nur ein paar Abweichungen zu merken) !

Dann doch lieber nur 1,2 Sprachen lernen als 2 :p

Gruß,

Simon2.

[Simon2]

DEvent schrieb:

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

...

Aber warum kann man auf die einen "Referenzen" (die, die auf Builtins zeigen) Operatoren anwenden (und keine Methoden), auf die anderen (auf Objekte) hingegen genau andersherum ?

Gruß,

Simon2.

[Simon2]

Töss schrieb:

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

Ah !! Ein Herr Oberlehrer hat reingeschaut !

Wie wär's wenn derjenige, der "die Schnauze voll vom Thema hat", einfach sich und uns die Zeit spart und nur Threads liest (und schreibt), die ihn interessieren ?

[Gast++]

Was mich allerdings schon wundert ist dass dieser Thread so gut wie unmoderiert ist.

Bei anderen Threads zum Thema

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

ist man sehr schnell mit Moderation zur Stelle.

Aber ichbin ja beharrlich

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

Grüsse

*this

[tntnet]

CStoll schrieb:

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

Mit const-correctness hast Du ein interessantes Thema angesprochen. Const-correctness ist sicherlich eine Sache, die sich dem Anfänger nicht so einfach erschliesst, aber bei richtiger Benutzung Fehler vermeiden hilft. Ich kann damit einfach in der Methodensignatur die Garantie geben, daß das Objekt nicht geändert wird und der Compiler überprüft das auch noch. Das ist eines der Features, die ich bei der Programmierung mit Java schmerzlich vermisse. Mir ist es des öfteren in Java passiert, daß ich ein übergebenes Objekt versehentlich geändert habe. Das kann mir mit const nicht passieren.

Ich war mal in so einem Java-Projekt, wo Belege verarbeitet wurden. Ich habe in der Oberfläche aus einer Liste von Belegen eines ausgewählt und editiert. Der Anwender hatte jetzt die Möglichkeit, die Bearbeitung abzubrechen und seine Änderungen zu verwerfen. Im ersten Versuch hatte ich mir (als alter C++-Programmierer) gedacht, ich speichere das Objekt, welches bearbeitet wurde einfach nicht zurück in die Liste, aus der ich es geholt hatte. Aber üblerweise hatte ich ja sowieso nur eine Referenz. Das zu fixen war dann doch nicht so einfach, wie es in einem sauberen C++-Programm der Fall gewesen wäre.

Ein C++-Programm hätte ich bereits beim Aufruf der Bearbeitungsmaske mich entscheiden müssen, ob ich das Objekt als Kopie oder als Referenz (oder Zeiger) übergebe. Hätte ich mich für die Referenz entschieden (const natürlich), hätte mir der Compiler was gehustet, wenn ich versucht hätte, es zu ändern.

[rüdiger]

Was ich an Java lustig finde, das sich

String a = "Foo";
String b = a;
b+="bar";

von dem unterscheidet was man bekommt, wenn man

MyString a = "Foo";
//ups das müsste glaube ich ohnenin MyString a = new MyString("Foo"); heißen
MyString b = a;
b.AddToMe("bar");

(Wobei AddToMe eben den String anfügt, so wie man es von += erwartet) benutzt.

Der +=-Operator scheint nämlich eine eigene Kopie des Objektes anzulegen. Während man das in einem AddToMe-"Operator" wohl nicht machen würde.

btw. würde das so gehen

this = this.clone();

wenn clone das Objekt kopiert?

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 ist ja auch von Anfang an zusammen gefrickelt gewesen. Ob man das OOP drauf klatscht oder nicht :p

[Simon2]

Gast++ schrieb:

Was mich allerdings schon wundert ist dass dieser Thread so gut wie unmoderiert ist....

Wundert mich auch, aber ich habe doch den Eindruck, dass hier ein recht gemäßigter Ton vorherrscht, was in anderen Threads nicht der Fall war.

Und letztlich ist es im Wesentlichen das Privatduell von CStoll und pale, das von ein paar Zuschauern kommentiert wird
Ich sehe da keine besondere "Flächenbrandgefahr".

Gruß,

Simon2.

[pale dog]

CStoll schrieb:

wenn ich in Java eine Objektkopie brauche, muß ich nach komplizierten Workarounds suchen, die noch dazu "besser nicht verwendet" werden sollten.

das hatten wir schon
ausserdem kann man in Java copy-ctors bauen, die nur das kopieren, was man als kopierwürdig erachtet (genau so wie in C++)

Simon2 schrieb:

pale dog schrieb:

...
aber jetzt kommt die hammerthese: wer C und Java hat/kann/nutzt braucht kein C++, niemals!...

Meine Hammerthese: Wer C++ hat/kann/nutzt, braucht kein Java, niemals (und C bekommt er quasi "geschenkt" - er braucht sich nur ein paar Abweichungen zu merken) !
Dann doch lieber nur 1,2 Sprachen lernen als 2 :p

so einfach ist das leider nicht.

nutzt man C++ für low-level, hardwarenahe programmierung, womöglich auf einer plattform mit wenig rechenpower und wenig speicher, dann muss man ganz genau aufpassen, was man tut. c++ verführt zu 'over-engineering' d.h. man macht sich ein tolles, 'C++-mässiges' programmdesign, aber verliert performance und braucht mehr speicher für code, variablen und C++ runtime libraries, als wenn man C verwendet hätte.
(ich gehe mal davon aus, dass C++ mir bei meinen microcontroller-projekten so manches bein weggeschossen hätte).

nimmt man C++ für high-levelige, grosse systeme, dann halst man sich übermässig lange planungs- und entwicklungszeiten auf und braucht extrem gut ausgebildete und erfahrene fachleute, die nicht billig sind. versucht man irgendwas davon einzusparen, sind zeitaufwendige debugging-sessions vorprogrammiert.
hier ist man mit Java (oder unter windoof mit .NET) besser bedient.

fazit: mit C++ geht zwar prinzipiell alles, aber es ist sehr risikoreich und wirtschaftlich oft ein schuss in den ofen.

[Konrad Rudolph]

Hi pale doggy,

pale dog schrieb:

fazit: mit C++ geht zwar prinzipiell alles, aber es ist sehr risikoreich und wirtschaftlich oft ein schuss in den ofen.

Guter Beitrag, gut auf den Punkt gebraucht (auch das, was davor stand) – nur, das bedeutet noch lange nicht, dass die Alternative Java wäre! Es sagt nichts darüber aus, ob Java eine gute Wahl wäre (und es wäre IMHO eine verdammt schlechte). Java teilt da durchaus einige Probleme mit C++. Du schriebst zum Beispiel, "c++ verführt zu 'over-engineering'" – korrekt. Aber: Java *ist* Over-engineering.Das wird dann immer damit rausgeredet, Java sei eben Industrie-stark. Quatsch. Python etc. sind genauso Industrie-stark. Java ist einfach fett. Und zwar "fett" im Sinne von übergewichtig und schwerfällig.

[CStoll]

Simon2 schrieb:

Gast++ schrieb:

Was mich allerdings schon wundert ist dass dieser Thread so gut wie unmoderiert ist....

Und letztlich ist es im Wesentlichen das Privatduell von CStoll und pale, das von ein paar Zuschauern kommentiert wird

Wenn's nur das wäre

pale dog schrieb:

CStoll schrieb:

wenn ich in Java eine Objektkopie brauche, muß ich nach komplizierten Workarounds suchen, die noch dazu "besser nicht verwendet" werden sollten.

das hatten wir schon
ausserdem kann man in Java copy-ctors bauen, die nur das kopieren, was man als kopierwürdig erachtet (genau so wie in C++)

Ja, hatten wir schon mehrfach, aber bisher (zumindest aus meiner Sicht) ohne echte Pluspunkte für Java. Den Copy-Ctor mußt du (a) erstmal an deine Bedürfnisse anpassen und (b) daran denken, daß du ihn explizit aufrufen mußt (warst du es oder kam das von Gregor - einer von "euch" hat zumindest erklärt, daß man zwar clone() anpassen könnte, aber besser die Finger davon lassen sollte).

[Simon2]

pale dog schrieb:

...
so einfach ist das leider nicht.

nutzt man C++ für low-level, hardwarenahe programmierung, womöglich auf einer plattform mit wenig rechenpower und wenig speicher, dann muss man ganz genau aufpassen, was man tut. c++ verführt zu 'over-engineering' d.h. man macht sich ein tolles, 'C++-mässiges' programmdesign, aber verliert performance und braucht mehr speicher für code, variablen und C++ runtime libraries, als wenn man C verwendet hätte.
(ich gehe mal davon aus, dass C++ mir bei meinen microcontroller-projekten so manches bein weggeschossen hätte)....

Ja - und ?
Wenn Du gründlich liest, fällt Dir vllt. auf, dass ich nicht geschrieben habe, man bräuchte C nicht mehr...

Den Sonderfall, in dem Du Java als C++ überlegen ansiehst, gibt es ebenso andersherum (wir schreiben z.B. performancerelevante und trotzdem große Programme mit hoher "OO-Affinität" und viel Bitfuddelei und einer Menge C-API-Nutzung). Wenn diese Ausnahmen für Dich kein Argument waren, doch "C++ zu brauchen", kann Dein Sonderfall auch kein Argument für einen Java-Bedarf darstellen.

BTW: In unserer Firma war Java der "wirtschaftliche Schuss in den Ofen", weil "der Pragmatismus" die Probleme in eine sehr kritische Phase (fachliche und technische Tests; tw. mit Kundenbeteiligung) verschob und dort Dinge, die jeder C++-Compiler merkt, höheren Schaden anrichteten.

Gruß,

Simon2.

[Artchi]

pale dog schrieb:

nimmt man C++ für high-levelige, grosse systeme, dann halst man sich übermässig lange planungs- und entwicklungszeiten auf und braucht extrem gut ausgebildete und erfahrene fachleute, die nicht billig sind. versucht man irgendwas davon einzusparen, sind zeitaufwendige debugging-sessions vorprogrammiert.
hier ist man mit Java (oder unter windoof mit .NET) besser bedient.

Aha, also nach deiner Meinung, würde es reichen, wenn in Stellenanzeigen folgendes stehen würde:

Java Programmierer gesucht
Für unser neues Projekt wird ein weniger gut ausgebildeter Java-Entwickler gesucht. Engineering-Kenntnisse müssen nicht vorhanden sein. Bitte keine Java-Entwickler mit sehr guten C++-Kenntnissen, da wir mit diesen schlechte Erfahrung beim Engineering gesammelt haben.
Bitte schicken Sie Ihre Bewerbungsunterlagen und Ihr Wunschgehalt an Frau Müller.

[Gast++]

Simon2 schrieb:

Gast++ schrieb:

Was mich allerdings schon wundert ist dass dieser Thread so gut wie unmoderiert ist....

Wundert mich auch, aber ich habe doch den Eindruck, dass hier ein recht gemäßigter Ton vorherrscht, was in anderen Threads nicht der Fall war.

Und letztlich ist es im Wesentlichen das Privatduell von CStoll und pale, das von ein paar Zuschauern kommentiert wird
Ich sehe da keine besondere "Flächenbrandgefahr".

Nein, Flächenbrände meinte ich auch nicht; eher im Gegenteil die Diskussion ist imo teilweise sehr substanziiert.

Ich meine eher "Moderieren" im Sinne von "Zusammenfassen" und ggf. mit Zustimmung kürzen.

Grüsse

*this