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

CStoll

pale dog schrieb:

CStoll schrieb:
MyIntType bi = new MyIntType(4711);
MyIntType bi2 = bi;
bi.Add(4);//das ändert sowohl den Wert von bi als auch von bi2
nein , ach menno , du verstehst es einfach nicht...
das
bi.Add(4);
verändert weder den wert von bi noch den wert von bi2
beide referenzen verweisen weiterhin auf das eine MyIntType-objekt.

Nein, du verstehst mich nicht: dem Anwender ist die "Referenz bi" egal (und nur ein Mittel zum Zweck) - für ihn zählt das "Objekt bi" (in C++ hätte ich das als MyIntType* bi = new MyIntType(4711); geschrieben und könnte jetzt klarer unterscheiden zwischen dem Zeiger bi und dem Objekt *bi). Und die "Objekte" bi und bi2 sind nunmal identisch - im Gegensatz zu den "Objekten" si und si2.

pale dog

CStoll schrieb:

dem Anwender ist die "Referenz bi" egal (und nur ein Mittel zum Zweck) - für ihn zählt das "Objekt bi"

mittel zum zweck natürlich schon, aber egal trotzdem nicht. man kann z.b. das objekt wegschmeissen mit 'bi = null; bi2 = null;', man kann bi oder bi2 auf ein neues objekt verweisen lassen usw. usw...

CStoll schrieb:

(in C++ hätte ich das als MyIntType* bi = new MyIntType(4711); geschrieben und könnte jetzt klarer unterscheiden zwischen dem Zeiger bi und dem Objekt *bi).

denk dir in Java das sternchen weg, dann stimmt's ja fast.
...oder versuch dich mal von dieser schrecklichen C++ sichtweise zu lösen, vielleicht fällt dir das verständnis dann leichter...

CStoll schrieb:

Und die "Objekte" bi und bi2 sind nunmal identisch - im Gegensatz zu den "Objekten" si und si2.

bi, bi2, si und si2 sind im sinne von Java keine objekte.

CStoll

pale dog schrieb:

CStoll schrieb:

dem Anwender ist die "Referenz bi" egal (und nur ein Mittel zum Zweck) - für ihn zählt das "Objekt bi"

mittel zum zweck natürlich schon, aber egal trotzdem nicht. man kann z.b. das objekt wegschmeissen mit 'bi = null; bi2 = null;', man kann bi oder bi2 auf ein neues objekt verweisen lassen usw. usw...

Möglich. Aber das ist nicht der Hauptzweck meiner Klassen Meine Klasse soll (z.B.) rechnen können und sich dabei möglichst genauso verwenden lassen wie die eingebauten int's - und jetzt verrat mir mal, wie du das hinbekommen willst.

CStoll schrieb:

(in C++ hätte ich das als MyIntType* bi = new MyIntType(4711); geschrieben und könnte jetzt klarer unterscheiden zwischen dem Zeiger bi und dem Objekt *bi).

denk dir in Java das sternchen weg, dann stimmt's ja fast.

Deswegen bleibt immer noch der Unterschied zwischen der Referenz bi und dem Objekt bi (in C++ *bi) - und die Frage, welche Operationen sich nun auf was beziehen.

...oder versuch dich mal von dieser schrecklichen C++ sichtweise zu lösen, vielleicht fällt dir das verständnis dann leichter...

Versuch du doch mal, dich von "dieser schrecklichen Java sichtweise" zu lösen, dann verstehst du womöglich auch die Argumente der Gegenseite.

CStoll schrieb:

Und die "Objekte" bi und bi2 sind nunmal identisch - im Gegensatz zu den "Objekten" si und si2.

bi, bi2, si und si2 sind im sinne von Java keine objekte.

Und da behauptet Java immer, objektorientiert zu sein

@Gregor: Und Java ist ausgereift? Nur die Tatsache, daß die Entwickler dort häufiger neue Versionen definieren, ist noch lange kein Zeichen für Qualität. Das C++ Kommitee durchdenkt die Verbesserungen halt gründlicher anstatt solche Schnellschüsse herauszubringen (die dann auf ewig im Sprachkonzept zurückbleiben).

Simon2

pale dog schrieb:

...man kann z.b. das objekt wegschmeissen mit 'bi = null; bi2 = null;', man kann bi oder bi2 auf ein neues objekt verweisen lassen usw. usw......

Naja ... "usw" ist schon ein wenig übertrieben. Mehr, als auf ein Objekt oder null verweisen und "calls weiterzureichen" zu lassen, kann man mit einer Referenz nicht machen.
Selbst "Wegschmeissen" geht eigentlich nicht; man kann höchstens "vergessen, dass man es kannte" (der GC kann es, wenn er Lust dazu hat, irgendwann wegschmeissen).

So eine Referenz ist schon ein recht beschränktes Ding.

Gruß,

Simon2.

Gregor

rüdiger schrieb:

Das in der C++-Welt sorgfältiger entschieden wird sehe ich eher als Vorteil an. Gerade die Generics zeigen doch was passiert, wenn man schnell schnell ein Feature mit dem x.y-Release rausbringen will, weil es die Sprache Z (hier eben C#) schon hat.

Das in der C++Welt sorgfältiger entschieden wird, scheint eine Grundannahme von Dir zu sein. Wie kommst Du eigentlich darauf? IMHO müssen die Änderungen, die da mit dem neuen Standard kommen, erst noch zeigen, dass da irgendetwas sorgfältiger gemacht wurde. Wie sieht es denn in der Vergangenheit aus? Ich kann mich da an folgendes erinnern: Als ich 2001 in dieses Forum gekommen bin, hat man C++ vorgeworfen, dass praktisch kein Compiler standardkonform ist. 3 Jahre nach dem 98er Standard. Das deutet schonmal darauf hin, dass die Standardisierung von der Infrastruktur bzw. von der Organisation her nicht besonders sorgfältig oder professionell ist. Ich kenne auch wen, der vor kurzem einen Job im C++ Umfeld angenommen hat, bei dem ihm erstmal ausdrücklich klar gemacht wurde, dass er Templates nur unter vorheriger Absprache in Ausnahmefällen nutzen darf. Deutet das auf ein sorgfältig ausgearbeitetes Sprachfeature hin? Wenn man es im produktiven Einsatz erstmal generell nicht nutzen darf?

BTW: Java hatte die Generics vor C#. ...nur, um das mal klarzustellen. Und der Vorschlag, Generics Java hinzuzufügen, kam eh lange bevor C# auch nur ein feuchter Traum der MS-Entscheidungsträger war.

rüdiger schrieb:

Und so hat man ja auch das Problem, dass die Sprache schon weiter ist, als die meisten Nicht-SUN-SDKs. IBM setzt ja immer noch auf Java 1.4.

JDK5 für AIX32, AIX64: http://www-128.ibm.com/developerworks/java/jdk/aix/service.html
JDK5 für Linux: http://www-128.ibm.com/developerworks/java/jdk/linux/download.html
JDK5 für z/OS: http://www-03.ibm.com/servers/eserver/zseries/software/java/

JDK6 early release für diverse Plattformen: https://www14.software.ibm.com/iwm/web/cc/earlyprograms/ibm/java6/index.shtml

Was genau meinst Du eigentlich?

Simon2

Gregor schrieb:

...hat man C++ vorgeworfen, dass praktisch kein Compiler standardkonform ist. 3 Jahre nach dem 98er Standard. ... Ich kenne auch wen, der vor kurzem einen Job im C++ Umfeld angenommen hat, bei dem ihm erstmal ausdrücklich klar gemacht wurde, dass er Templates nur unter vorheriger Absprache in Ausnahmefällen nutzen darf. Deutet das auf ein sorgfältig ausgearbeitetes Sprachfeature hin? Wenn man es im produktiven Einsatz erstmal generell nicht nutzen darf?...

Nicht, dass ich prinzipiell widersprechen wollte, ich finde das nur lustig. Es zeigt IMO den klassischen "Paradigmenkonflikt" zwischen Java- und C++Denke. Javaisten sind eher am schnellen Praxiseinsatz und C++er eher an "konzeptioneller Reinheit" interessiert (natürlich nur tendentiell und verallgemeinert).
Die einen neigen zum "zu kurz springen", die Anderen zum zum "gar nicht springen" (Mein Chef sagte immer so schön: "Man kann auch in Schönheit sterben !")

Gruß,

Simon2.

Gregor

CStoll schrieb:

Und da behauptet Java immer, objektorientiert zu sein

Aus meiner Sicht geht es bei Java nicht darum, möglichst objektorientiert zu sein. Es geht vielmehr darum, Entwicklern ein Werkzeug zur Verfügung zu stellen, mit dem sie effektiv und effizient entwickeln können. Ein Werkzeug, mit dem sie ihre Vorhaben geradlinig und direkt realisieren können, ohne sich sich den vielfältigen Möglichkeiten des Werkzeugs zu verlieren. Es geht mehr um den "goldenen Mittelweg" aus technischen Interessen, wirtschaftlichen Interessen und so weiter. Also um Pragmatismus.

CStoll schrieb:

@Gregor: Und Java ist ausgereift? Nur die Tatsache, daß die Entwickler dort häufiger neue Versionen definieren, ist noch lange kein Zeichen für Qualität. Das C++ Kommitee durchdenkt die Verbesserungen halt gründlicher anstatt solche Schnellschüsse herauszubringen (die dann auf ewig im Sprachkonzept zurückbleiben).

Ich habe nirgendwo behauptet, dass Java ausgereift ist. Aber die Schwachstellen von Java werden stärker angegangen, als das in der C++Welt der Fall ist. Da konnte man sich ja auch beim nächsten Standard noch nicht darauf verständigen, C++ eine umfassende Standardbibliothek zu verpassen. ...eine ganz massive Schwachstelle, die einfach mit dem Hinweis auf Toaster usw. ignoriert wird.

Gregor

Simon2 schrieb:

Gregor schrieb:

...hat man C++ vorgeworfen, dass praktisch kein Compiler standardkonform ist. 3 Jahre nach dem 98er Standard. ... Ich kenne auch wen, der vor kurzem einen Job im C++ Umfeld angenommen hat, bei dem ihm erstmal ausdrücklich klar gemacht wurde, dass er Templates nur unter vorheriger Absprache in Ausnahmefällen nutzen darf. Deutet das auf ein sorgfältig ausgearbeitetes Sprachfeature hin? Wenn man es im produktiven Einsatz erstmal generell nicht nutzen darf?...

Nicht, dass ich prinzipiell widersprechen wollte, ich finde das nur lustig. Es zeigt IMO den klassischen "Paradigmenkonflikt" zwischen Java- und C++Denke. Javaisten sind eher am schnellen Praxiseinsatz und C++er eher an "konzeptioneller Reinheit" interessiert (natürlich nur tendentiell und verallgemeinert).

Dem stimme ich zu. Die Frage ist halt, was man selbst erreichen möchte. Das perfekte Programm? Unabhängig von den Kosten? Dann ist C++ sicherlich die erste Wahl. Aber dann betreibt man das Programmieren auch zum Selbstzweck.

Jester

CStoll schrieb:

Das C++ Kommitee durchdenkt die Verbesserungen halt gründlicher anstatt solche Schnellschüsse herauszubringen (die dann auf ewig im Sprachkonzept zurückbleiben).

Redest Du von export?

Konrad Rudolph

Gregor schrieb:

BTW: Java hatte die Generics vor C#. ...nur, um das mal klarzustellen.

Ist aber irrelevant, denn die .NET-Generics sind trotzdem um Welten besser implementiert als die in Java. – Und das ist echt schlimm, denn die .NET-Generics sind wirklich grottenschlecht und außer für allgemeine Containerklassen und einige simple Abstraktionen kaum zu gebrauchen.

Simon2

Gregor schrieb:

...Das perfekte Programm? Unabhängig von den Kosten? Dann ist C++ sicherlich die erste Wahl. Aber dann betreibt man das Programmieren auch zum Selbstzweck.

Schön !!

Gruß,

Simon2.

CStoll

Gregor schrieb:

CStoll schrieb:

Und da behauptet Java immer, objektorientiert zu sein

Aus meiner Sicht geht es bei Java nicht darum, möglichst objektorientiert zu sein. Es geht vielmehr darum, Entwicklern ein Werkzeug zur Verfügung zu stellen, mit dem sie effektiv und effizient entwickeln können. Ein Werkzeug, mit dem sie ihre Vorhaben geradlinig und direkt realisieren können, ohne sich sich den vielfältigen Möglichkeiten des Werkzeugs zu verlieren. Es geht mehr um den "goldenen Mittelweg" aus technischen Interessen, wirtschaftlichen Interessen und so weiter. Also um Pragmatismus.

OK, bleiben wir mal bei einem meiner letzten Beispiele: Wie kann ich in Java eine (z.B.) BigInt-Klasse entwickeln, die möglichst nahe an der natürlichen Semantik von int's liegt? Ein möglichst einfach zu nutzendes Werkzeug ist sicher recht praktisch, nur leider schränkt es neben den Problemfeldern auch die möglichen Anwendungsbereiche ein.
(wo du schon von Werkzeugen sprichst: ein Kreuzschlitz-Schraubendreher ist auch einfacher zu handhaben als ein Akkuschrauber ;))

pale dog

CStoll schrieb:

pale dog schrieb:

CStoll schrieb:

dem Anwender ist die "Referenz bi" egal (und nur ein Mittel zum Zweck) - für ihn zählt das "Objekt bi"

mittel zum zweck natürlich schon, aber egal trotzdem nicht. man kann z.b. das objekt wegschmeissen mit 'bi = null; bi2 = null;', man kann bi oder bi2 auf ein neues objekt verweisen lassen usw. usw...

Möglich. Aber das ist nicht der Hauptzweck meiner Klassen Meine Klasse soll (z.B.) rechnen können und sich dabei möglichst genauso verwenden lassen wie die eingebauten int's - und jetzt verrat mir mal, wie du das hinbekommen willst.

die klassen in Java können das, wofür sie gemacht wurden, das ist in deiner lieblingssprache auch nicht anders
aber wieso sollten sich objekte wie eingebaute ints verwenden lassen?
das würde doch mehr verwirrung stiften als nützen.
wenn du z.b. in C programmierst, ist es doch auch von bedeutung, ob du mit einem int, float, oder array arbeitest.
objekte zu 'tarnen' und sie wie etwas anderes aussehen zu lassen, macht wenig sinn, das ist bestenfalls eine fehlinterpretation von 'information hiding'.

CStoll schrieb:

Und da behauptet Java immer, objektorientiert zu sein

ist es ja auch, es übertreibt nur nicht damit.

Gregor

CStoll schrieb:

OK, bleiben wir mal bei einem meiner letzten Beispiele: Wie kann ich in Java eine (z.B.) BigInt-Klasse entwickeln, die möglichst nahe an der natürlichen Semantik von int's liegt?

Im Allgemeinen würdest Du Dich in Java gar nicht mit der Programmierung so einer Klasse aufhalten, sondern eher java.lang.BigInteger nehmen. ..wow: Wieviel Zeit Du dadurch in der Entwicklung gespart hast! Unfassbar.

CStoll

pale dog schrieb:

CStoll schrieb:

pale dog schrieb:

CStoll schrieb:

dem Anwender ist die "Referenz bi" egal (und nur ein Mittel zum Zweck) - für ihn zählt das "Objekt bi"

mittel zum zweck natürlich schon, aber egal trotzdem nicht. man kann z.b. das objekt wegschmeissen mit 'bi = null; bi2 = null;', man kann bi oder bi2 auf ein neues objekt verweisen lassen usw. usw...

Möglich. Aber das ist nicht der Hauptzweck meiner Klassen Meine Klasse soll (z.B.) rechnen können und sich dabei möglichst genauso verwenden lassen wie die eingebauten int's - und jetzt verrat mir mal, wie du das hinbekommen willst.

die klassen in Java können das, wofür sie gemacht wurden, das ist in deiner lieblingssprache auch nicht anders

Aber wenn ich künstlich darin beschränkt werde, was ich meinen Klassen beibringen darf, sehe ich den Sinn dahinter nicht.

aber wieso sollten sich objekte wie eingebaute ints verwenden lassen?
das würde doch mehr verwirrung stiften als nützen.

Gegenfrage: Warum sollen "meine" BigInt's sich anders verhalten als die eingebauten int's? Beide stellen eine Zahl dar, also sollte man auch mit beiden vernünftig (und unter vergleichbaren Bedingungen) rechnen können.

wenn du z.b. in C programmierst, ist es doch auch von bedeutung, ob du mit einem int, float, oder array arbeitest.

(*schaut auf den Thread-Titel*) C steht hier aber nicht zur Debatte.

objekte zu 'tarnen' und sie wie etwas anderes aussehen zu lassen, macht wenig sinn, das ist bestenfalls eine fehlinterpretation von 'information hiding'.

Eine Zahl in einem Objekt zu verstecken und ihre Verwendung hinter irgendwelchen Methoden zu verbergen, macht noch weniger Sinn. Und wenn, dann sollte Java bitte so konsequent sein und auch int und Kollegen als Objekte anbieten.

CStoll schrieb:

Und da behauptet Java immer, objektorientiert zu sein

ist es ja auch, es übertreibt nur nicht damit.

Wenn es objektorientiert ist, warum drückt es mir dann keine Objekte in die Hand?

Edit @Gregor:

Gregor schrieb:

CStoll schrieb:

OK, bleiben wir mal bei einem meiner letzten Beispiele: Wie kann ich in Java eine (z.B.) BigInt-Klasse entwickeln, die möglichst nahe an der natürlichen Semantik von int's liegt?

Im Allgemeinen würdest Du Dich in Java gar nicht mit der Programmierung so einer Klasse aufhalten, sondern eher java.lang.BigInteger nehmen. ..wow: Wieviel Zeit Du dadurch in der Entwicklung gespart hast! Unfassbar.

Erstens: Kann man BigInteger-Werte genauso verwenden wie 'normale' int's?

Und zweitens: Die BigInt waren nur ein Beispiel Aber ich bin mir sicher, du kennst die Java-Bibliothek besser als ich - und kannst dort auch für jeden Zweck die perfekte Klasse ausgraben.

Gregor

CStoll schrieb:

Wenn es objektorientiert ist, warum drückt es mir dann keine Objekte in die Hand?

Wenn man von der Objektorientiertheit von Java spricht, dann meint man doch nicht, dass OOP da zu 100% perfekt umgesetzt wird. Meistens werden solche Bemerkungen im Vergleich zu C++ gemacht. Und man spricht dabei vor allem Anfänger an. C++ ist im Gegensatz zu Java eine Multiparadigmensprache: Insofern hat der Anfänger, der sich u.a. noch nicht mit OOP auskennt, erstmal ganz viele Wege offen, wie er etwas erreichen kann. Wenn es dem Anfänger allerdings darum geht, OOP zu lernen, dann ist das nicht hilfreich. Java setzt da geradliniger auf OOP, ohne es damit zu übertreiben. Aus diesem Grund trifft man in OOP-Vorlesungen auch eher Java als C++ zur Illustration der verschiedenen Konzepte an.

Simon2

Gregor schrieb:

CStoll schrieb:

OK, bleiben wir mal bei einem meiner letzten Beispiele: Wie kann ich in Java eine (z.B.) BigInt-Klasse entwickeln, die möglichst nahe an der natürlichen Semantik von int's liegt?

Im Allgemeinen würdest Du Dich in Java gar nicht mit der Programmierung so einer Klasse aufhalten, sondern eher java.lang.BigInteger nehmen. ...

Mal aus Interesse: Wie ist denn java.lang.BigInteger geschrieben ? Können die mehr als der normale Javaprogrammierer ?

Gregor schrieb:

...[C++] ...erstmal ganz viele Wege offen, wie er etwas erreichen kann. Wenn es dem Anfänger allerdings darum geht, OOP zu lernen, dann ist das nicht hilfreich. Java setzt da geradliniger auf OOP, ohne es damit zu übertreiben. Aus diesem Grund trifft man in OOP-Vorlesungen auch eher Java als C++ zur Illustration der verschiedenen Konzepte an.

eben "frei" vs. "den"

Gruß,

Simon2.

Gregor

CStoll schrieb:

Und zweitens: Die BigInt waren nur ein Beispiel Aber ich bin mir sicher, du kennst die Java-Bibliothek besser als ich - und kannst dort auch für jeden Zweck die perfekte Klasse ausgraben.

Wie schon gesagt: Um Perfektionismus geht es nur bei C++. Bei Java geht es um Resultate. Und der Kompromiss, eine Klasse aus der Standardbibliothek zu nehmen, anstatt einer selbstgeschriebenen Klasse, die etwas besser passen würde, ist oft ein sehr guter Kompromiss. Vor allem, wenn man bedenkt, dass hinter Klassen der Standardbibliothek sehr viel Aufwand steckt. Die Leute, die daran arbeiten, verstehen ihr Handwerk. Die haben viel Zeit investiert, um verschiedene Algorithmen usw. zu evaluieren und so eine Klasse ist das Resultat davon. Nicht nur das, sondern in die Standardbibliothek wird auch unabhängig von Dir weiterhin jede Menge Arbeit gesteckt. Die Klassen dort werden mit der Zeit besser (zum Beispiel performanter).

Im Übrigen machen viele Operatoren, die man bei ints nutzt, bei BigIntegers deutlich weniger Sinn. Zum Beispiel die ganzen Bit-Operatoren. Insofern sollte man die möglichst gleichartige Verwendung durchaus in Frage stellen.

Gregor

Simon2 schrieb:

Mal aus Interesse: Wie ist denn java.lang.BigInteger geschrieben ? Können die mehr als der normale Javaprogrammierer ?

Ganz normale Javaklasse. ...früher war die AFAIK über JNI implementiert. Aber es hat sich glaube ich herausgestellt, dass Java da alleine performanter arbeitet.

CStoll

Gregor schrieb:

CStoll schrieb:

Und zweitens: Die BigInt waren nur ein Beispiel Aber ich bin mir sicher, du kennst die Java-Bibliothek besser als ich - und kannst dort auch für jeden Zweck die perfekte Klasse ausgraben.

Wie schon gesagt: Um Perfektionismus geht es nur bei C++. Bei Java geht es um Resultate. Und der Kompromiss, eine Klasse aus der Standardbibliothek zu nehmen, anstatt einer selbstgeschriebenen Klasse, die etwas besser passen würde, ist oft ein sehr guter Kompromiss. Vor allem, wenn man bedenkt, dass hinter Klassen der Standardbibliothek sehr viel Aufwand steckt. Die Leute, die daran arbeiten, verstehen ihr Handwerk. Die haben viel Zeit investiert, um verschiedene Algorithmen usw. zu evaluieren und so eine Klasse ist das Resultat davon. Nicht nur das, sondern in die Standardbibliothek wird auch unabhängig von Dir weiterhin jede Menge Arbeit gesteckt. Die Klassen dort werden mit der Zeit besser (zum Beispiel performanter).

Genauso kannst du in C++ mit den verfügbaren Bibliotheken arbeiten (die Standard Bibliothek ist recht umfangreich - und daneben gibt es auch Boost und die OS-Libs wie MFC).

Im Übrigen machen viele Operatoren, die man bei ints nutzt, bei BigIntegers deutlich weniger Sinn. Zum Beispiel die ganzen Bit-Operatoren. Insofern sollte man die möglichst gleichartige Verwendung durchaus in Frage stellen.

OK, lassen wir mal Bit-Operatoren außen vor, aber wie sieht es aus, wenn man zwei BigInteger's verrechnen will? Kann ich einfach bi3 = bi2*bi1; schreiben? Und wenn ja, wie haben die Java entwickler das bewerkstelligt?