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

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.

Jester

Simon2 schrieb:

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

Interessante Bennennung der Parameter. Nur imho leicht verwirrend.

dot

die benennung is nicht unbedingt so exotisch.
rhs = right hand side, lhs = left hand side...da hat sich jemand was von scotty abgeguckt :p

LordJaxom

dot schrieb:

die benennung is nicht unbedingt so exotisch.
rhs = right hand side, lhs = left hand side...da hat sich jemand was von scotty abgeguckt :p

Dann sollte Scotty besser nicht das Schiff navigieren

Simon2

Jajaja ... Ihr habt ja Recht !

Gruß,

Simon2.

Wie lange wollt ihr euch noch bekriegen?

pale dog

Simon2 schrieb:

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.

kannst du das etwas genauer beschreiben?
was hätte ein C++ compiler gemerkt?
...und warum hattet ihr pech mit Java?

DEvent

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.

Wir haben ja schon festgestellt, das man in Java nur mit Referenzen zu tun hat. Const-Methoden habe ich in Java bis jetzt noch nicht vermisst. Wenn ich eine Methode foo.setXxx(); aufrufe, dann ist doch wohl klar, das sie den internen Status des Objekts verändert. Du hast eher die Sprachen vermischt (C++ und Java) und hast gedacht das Java sich genauso wie C++ verhalten würde.

Stand nicht ein Spruch in Modern Java Design (oder so): Man sollte eine Klasse immer als immutable designen, es seih den man hat gute Gründe es nicht zu tun. Wenn solche Gründe vorliegen, sollte man zwei Klassen designen, eine immutable und eine mutable.

Was ist eigentlich schwer an Objekte kopieren, wenn man Java benutzt?
- entweder man überschreibt die clone() Methode
- oder man erstellt einen Copy-Constructor
- oder man verwendet ObjectStream
- oder man verwendet Serialisierung
Das ist doch in C++ genauso.

CStoll

DEvent schrieb:

Wir haben ja schon festgestellt, das man in Java nur mit Referenzen zu tun hat. Const-Methoden habe ich in Java bis jetzt noch nicht vermisst. Wenn ich eine Methode foo.setXxx(); aufrufe, dann ist doch wohl klar, das sie den internen Status des Objekts verändert. Du hast eher die Sprachen vermischt (C++ und Java) und hast gedacht das Java sich genauso wie C++ verhalten würde.

Und das Zauberwort in diesem Satz ist "ich". Solange ich der einzige bin, der mit meinen Objekten hantiert, ist alles schön und gut - und ich brauche mich um Const-Correctness nicht zu kümmern. Aber in einem größeren Projekt gibt es auch noch meine Mitarbeiter, die auch mit meinen Klassen arbeiten wollen - und von denen weiß ich im schlimmsten Fall nur, daß sie ein Objekt entgegennehmen und damit arbeiten wollen. (in C++ kann ich mit dem Kollegen aushandeln, daß die entsprechende Methode ein 'const T&' erhält und der Compiler verhindert, daß er irgendwas an meinen Objekten ändert - in Java muß ich darauf vertrauen, daß er keine "verbotene" Methode aufruft).

Stand nicht ein Spruch in Modern Java Design (oder so): Man sollte eine Klasse immer als immutable designen, es seih den man hat gute Gründe es nicht zu tun. Wenn solche Gründe vorliegen, sollte man zwei Klassen designen, eine immutable und eine mutable.

Ja, immutable Klassen sind sicher praktisch - nur wie bekomme ich in Java die Verbindung zwischen diesen "zwei Klassen" hin?

Was ist eigentlich schwer an Objekte kopieren, wenn man Java benutzt?
- entweder man überschreibt die clone() Methode

Ich glaube Gregor war es, der meinte, daß eine wirklich brauchbare clone() Methode nicht gerade trivial ist und besser gar nicht angesehen werden sollte (der Thread ist leider zu umfangreich, um den entsprechenden Beitrag wiederzufinden)

- oder man erstellt einen Copy-Constructor

Da gilt (vermutlich) das selbe wie für clone() (andernfalls wäre clone() ja trivial lösbar)

- oder man verwendet ObjectStream
- oder man verwendet Serialisierung

Dazu hat mir immer noch niemand erklärt, wozu der Umweg überhaupt notwendig ist.

Das ist doch in C++ genauso.

Fast - C++ bietet per Default die Möglichkeit an, Objekte zu kopieren (das äußert sich schon in den impliziten Copy-Ctoren und Zuweisungsoperatoren) und man muß nur eingreifen, wenn das Default-Verhalten nicht ausreicht. Java macht es einem da unnötig schwer.

DEvent

Fast - C++ bietet per Default die Möglichkeit an, Objekte zu kopieren (das äußert sich schon in den impliziten Copy-Ctoren und Zuweisungsoperatoren) und man muß nur eingreifen, wenn das Default-Verhalten nicht ausreicht. Java macht es einem da unnötig schwer.

Wo bitte macht es Java einem schwerer? Probleme gibts doch nur bei einer tiefen Kopie und da gibt sich Java und C++ nichts.

Ja, immutable Klassen sind sicher praktisch - nur wie bekomme ich in Java die Verbindung zwischen diesen "zwei Klassen" hin?

interface PointInterface
{
    int getX();
    int getY();
}

final class Point implements PointInterface
{
    private final x;
    private final y;
    public Point(int x, int y);
    int getX() { return x; }
    int getY() { return y; }
}

class MutablePoint implements PointInterface
{
    private x;
    private y;
    public MutablePoint(int x, int y);
    public MutablePoint(PointInterface point) { x = point.getX(); y = point.getY(); }
    int getX() { return x; }
    int getY() { return y; }
    void setX(int x);
    void setY(int y);
}

//... da PointInterface nur getter hat, ist es const-correct
PointInterface point = new Point(10, 10);

//... nun hat man eine Kopie von point, die man ändern kann
m_point = new MutablePoint(point);

//... immer noch const-correct, man kann aber explizit casten, um setter zu benutzen
PointInterface point = new MutablePoint(10, 10);

Dazu hat mir immer noch niemand erklärt, wozu der Umweg überhaupt notwendig ist.

Wieso ist das ein Umweg? In Java kommst du fast immer damit aus keine Kopien anzulegen. Eine Kopie von einem Objekt zu machen ist ein extremer Spezialfall und da ist es berechtigt es so explizit wie möglich machen zu müssen. Bei einfachen Klassen hast du sowieso Null Aufwand wenn du Serialisierst/die Streams benutzt.

Nenn doch mal ein Beispiel, wo Java einem richtige Steine in den Weg legt.

Fast - C++ bietet per Default die Möglichkeit an, Objekte zu kopieren (das äußert sich schon in den impliziten Copy-Ctoren und Zuweisungsoperatoren) und man muß nur eingreifen, wenn das Default-Verhalten nicht ausreicht. Java macht es einem da unnötig schwer.

Man kann sagen dass das default-Verhalten von Java eben ist, das man keine Kopien erzeugt. Man muss halt explizit sagen das man eine Kopie will. Das Verhalten finde ich eigentlich recht gut und passend.

Konrad Rudolph

… Und genau das meinte ich damit, dass Java schwerfällig ist. Natürlich ist das ein guter Code. Aber verdammt, der Programmierer ist doch nicht dafür da, irgendwelchen bescheuerten Boilerplate code zu schreiben. Das soll gefälligst der Compiler für mich übernehmen, während ich als Programmierer mein wertvolles geistiges Potential dafür einsetze, die Logik zu implementieren, anstatt einen Sekretärinnenjob zu machen. Die Aufgabe des Computers ist es doch, mir die Arbeit abzunehmen. Also, da hat Java noch einen weiten Weg zu gehen.

Abgesehen davon führt das alles doch nur dazu, dass sich die Anzahl der Fehler, die man automatisch in den Code baut, multipliziert. Ich halte es für eines der grundsätzlichen Paradigmen, dass eine gute Sprache dem Programmierer das Codeschreiben so weit wie möglich abnimmt (und das heißt: eben *keinen* Boilerplate code schreiben), um die Fehlerwahrscheinlichkeit zu minimieren. Java tut das Gegenteil.

(C++ in gewissem Grad auch, aber aus einem sehr unterschiedlichen Grund.)

=> Eine Sprache, die den Programmierer dazu zwingt, solchen Code zu schreiben ist, mit Verlaub, Schrott.

CStoll

Da kann ich mich Konrad nur anschließen - es kann doch nicht angehen, daß ich drei Klassen (PointInterface, Point und MutablePoint) schreiben und untereinander konsistent halten muß, nur um mein Programm const-korrekt zu machen.

DEvent schrieb:

Dazu hat mir immer noch niemand erklärt, wozu der Umweg überhaupt notwendig ist.

Wieso ist das ein Umweg? In Java kommst du fast immer damit aus keine Kopien anzulegen. Eine Kopie von einem Objekt zu machen ist ein extremer Spezialfall und da ist es berechtigt es so explizit wie möglich machen zu müssen. Bei einfachen Klassen hast du sowieso Null Aufwand wenn du Serialisierst/die Streams benutzt.

Klar habe ich den Aufwand - ich muß überall, wo's benötigt wird, den Read-und-Write-Code einbauen. Und ich muß dafür sorgen, daß meine Klasse serialisierbar wird (klar reicht in vielen Fällen ein "implements serializable" dafür, aber offenbar nicht in allen Fällen).

Fast - C++ bietet per Default die Möglichkeit an, Objekte zu kopieren (das äußert sich schon in den impliziten Copy-Ctoren und Zuweisungsoperatoren) und man muß nur eingreifen, wenn das Default-Verhalten nicht ausreicht. Java macht es einem da unnötig schwer.

Man kann sagen dass das default-Verhalten von Java eben ist, das man keine Kopien erzeugt. Man muss halt explizit sagen das man eine Kopie will. Das Verhalten finde ich eigentlich recht gut und passend.

Aber es ist deutlich schwerer, Java Wert-Semantik beizubringen, als in C++ mit Referenzsemantik zu arbeiten. Und in der Anwendung werden beide Wege gelegentlich benötigt (klar, komplexe Klassen wie ein Auto verwendet man vermutlich besser über Referenzen, aber Hilfsklassen wie int's (da geht's witzigerweise) oder Point (als UDT auf Referenzsemantik festgelegt) sollten auch als Wert verwendet werden können.