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

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

Simon2

Hi,

ach so !

Dem stimme ich auch zu.

Gruß,

Simon2.

CStoll

Gast++ schrieb:

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.

Ja, dem würde ich auch zustimmen. Aber welchem Moderator würdest du es zumuten wollen, den Thread durchzusehen und auszusortieren?

Gast++

@CStoll
Ach, hallo Herr Moderator!

CStoll schrieb:

Ja, dem würde ich auch zustimmen. Aber welchem Moderator würdest du es zumuten wollen, den Thread durchzusehen und auszusortieren?

Viellicht mutet es sich ja jemand selbst zu....

Will ja niemanden scharf ansehen, aber:

Ich spendier auch 400 frische binäre Nullen aus meinem Zerodevice!
Händisch gepiped und checkgesummed!

Grüsse

*this

CStoll

Gast++ schrieb:

@CStoll
Ach, hallo Herr Moderator!

CStoll schrieb:

Ja, dem würde ich auch zustimmen. Aber welchem Moderator würdest du es zumuten wollen, den Thread durchzusehen und auszusortieren?

Viellicht mutet es sich ja jemand selbst zu....

Durchsehen könnte ich den Thread vielleicht, aber aussortieren (leider) nicht. Und ob ich die nötige Zeit hätte, mich darum zu kümmern, ist die andere Frage.

Ich spendier auch 400 frische binäre Nullen aus meinem Zerodevice!
Händisch gepiped und checkgesummed!

Danke für das Angebot, aber ich verzichte gerne. Ich hab' hier selber noch mehr als genug binäre Nullen rumliegen, die ich ohnehin erst sortieren und verbrauchen muß

Simon2

CStoll schrieb:

...Ich hab' hier selber noch mehr als genug binäre Nullen rumliegen, die ich ohnehin erst sortieren ...

bool operator<(CStollNull const& rhs, CStollNull const& lhs);

Gruß,

Simon2.

CStoll

Simon2 schrieb:

CStoll schrieb:

...Ich hab' hier selber noch mehr als genug binäre Nullen rumliegen, die ich ohnehin erst sortieren ...
bool operator<(CStollNull const& rhs, CStollNull const& lhs);
Gruß,

Simon2.

Ja, daran hatte ich auch schon gedacht, nur an der Umsetzung hängt's noch

LordJaxom

Ausserdem ist das C als Präfix für Klassen total out!!1

*duck*

Artchi

Wenn man Adobes "Possible Future" Glauben schenken darf, liegt trotz dem starken Kommen von Java und C# die Zukunft in der Template- und Metaprogrammierung, vorallem was die Library-Entwicklung angeht. Und ich denke mal, Adobe ist kein Hobby-Verein, die machen schon ernsthafte Software-Entwicklung. Ihr GIL beweist in welche Richtung bei ihnen die Entwicklung hingeht. Kennt jemand Adobe Lightroom? Das Ding ist erst neu auf dem Markt erschienen (also kein historisch gewachsenes Produkt) und recht groß (kein Bildviewer, sondern mit Datenbank, Publishing und dem ganzen anderen Pipapo für Fotografen). Wichtig: es ist zu 60% in C++ und 40% in Lua entwickelt (Lua ist als Scripting eingebettet). Diese kombination finde ich sehr interessant und macht vieles wett, was man für Java ggü. C++ propagiert. Trotzdem taucht bei Adobe nicht im geringsten Java oder C# als aktiv eingesetzte Sprache auf. Deshalb ist hier in diesem Thread das Infragestellen von C++' Zukunft einfach nur lächerlich. Die Praxisberichte zeigen es.

Simon2

LordJaxom schrieb:

Ausserdem ist das C als Präfix für Klassen total out!!1

*duck*

Stimmt - aber in Vornamen sind sie doch noch erlaubt, oder ?

Gruß,

Simon2.