c++ vs. java... was hat zukunft
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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?
-
CStoll schrieb:
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?Du weißt doch eh, dass man sich bei Java gegen das Operator-Overloading entschieden hat. Eine Designentscheidung, die sicherlich sowohl positive, als auch negative Aspekte hat. Ich habe es bisher zumindest noch nicht stark vermisst. Insofern nutzt Du da natürlich einen ganz normalen Methodenaufruf.
Prinzipiell könnte dort natürlich eine spezielle Behandlung eingebaut werden. Bei der String-Klasse wird das ja gemacht. ...und führt dort immer wieder zur Verwirrung.
-
Gregor schrieb:
Du weißt doch eh, dass man sich bei Java gegen das Operator-Overloading entschieden hat. Eine Designentscheidung, die sicherlich sowohl positive, als auch negative Aspekte hat. Ich habe es bisher zumindest noch nicht stark vermisst.
Hm. Das scheint echt ein Mentalitätsunterschied zu sein. Ich bin fast verrückt geworden, als ich für einen Kurs in Java neuronale Netze implementieren musste und dafür die Jama-Matrixklassen verwendet habe. Und das ging nicht nur mir so sondern allen anderen Kursteilnehmern auch. Es ist einfach extrem blöd, wenn man ohnehin schon komplexe Formeln (na ja … Gauss-Verteilungen und so) durch eine dermaßen textintensive Code-Umsetzung noch komplexer macht. Finde da mal nen Fehler drin.
-
Gregor schrieb:
CStoll schrieb:
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?Du weißt doch eh, dass man sich bei Java gegen das Operator-Overloading entschieden hat. Eine Designentscheidung, die sicherlich sowohl positive, als auch negative Aspekte hat. Ich habe es bisher zumindest noch nicht stark vermisst. Insofern nutzt Du da natürlich einen ganz normalen Methodenaufruf.
Und was haben wir davon? Jede Zahlenklasse verwendet ihre eigenen Methodennamen (und Parameterkombinationen), um eine bestimmte Operation umzusetzen. Auch nicht gerade förderlich.
Prinzipiell könnte dort natürlich eine spezielle Behandlung eingebaut werden. Bei der String-Klasse wird das ja gemacht. ...und führt dort immer wieder zur Verwirrung.
Erzähl mehr. Hat die String-Klasse tatsächlich überladene Operatoren? Und wenn ja, wie wurde das erreicht?
-
CStoll schrieb:
pale dog schrieb:
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.
was meinst du mit 'künstlich' beschränkt?
irgendwelche beschränkungen gibt's ja in jeder programmiersprache.CStoll schrieb:
pale dog schrieb:
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.
schau dir mal die methoden von 'BigInteger' an, ist eigentlich alles dabei, was man braucht und mehr (primzahlentest, gcd ;)). intern sind die natürlich anders aufgebaut als die eingebauten int's, aber das ist für den anwender, der damit rechnen will, etc. normalerweise von geringerer bedeutung.
also, was vermisst du?CStoll schrieb:
CStoll schrieb:
Und da behauptet Java immer, objektorientiert zu sein
pale dog schrieb:
ist es ja auch, es übertreibt nur nicht damit.
Wenn es objektorientiert ist, warum drückt es mir dann keine Objekte in die Hand?
wie meinst du denn das?
willst du irgendwelche objekte gleich beim start des programms haben
oder dass 'alles' ein objekt ist, auch einfache ganzzahlen?
-
Nicht nur bei "String", es gibt (soweit ich weiss) für jeden primitiven Datentyp eine Wrapperklasse ala Integer für ints, Double für Double usw.
Diese Klassen (und auch nur diesen!) wurde eine Operaterüberladung verpasst, sprich man kann mit ihnen rechnen als ob es primitivie Datentypen wären.
Gruß Baracke
-
CStoll schrieb:
Erzähl mehr. Hat die String-Klasse tatsächlich überladene Operatoren? Und wenn ja, wie wurde das erreicht?
Auf dem einfachsten Weg: Per Sprachdefinition.
Der Compiler wandelt das dann in entsprechende Methodenaufrufe um.
-
pale dog schrieb:
CStoll schrieb:
pale dog schrieb:
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.
was meinst du mit 'künstlich' beschränkt?
irgendwelche beschränkungen gibt's ja in jeder programmiersprache.Ich meinte damit solche Beschränkungen, daß man erstmal einen ByteStream benötigt, um ein Objekt echt zu kopieren. Oder daß die Rechenmethoden für jeden Zahlentyp anders heißen (können) und anders angewendet werden. Wenn ich zwei Werte multiplizieren will, schreibe ich "c=a*b;" und will mich nicht darum kümmern, ob das jetzt int's, BigInteger's oder MyOwnInt's sind (und wie dort die Multiplikationsmethode heißt).
CStoll schrieb:
pale dog schrieb:
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.
schau dir mal die methoden von 'BigInteger' an, ist eigentlich alles dabei, was man braucht und mehr (primzahlentest, gcd ;)). intern sind die natürlich anders aufgebaut als die eingebauten int's, aber das ist für den anwender, der damit rechnen will, etc. normalerweise von geringerer bedeutung.
also, was vermisst du?Sieh oben - selbst wenn sie alles haben, sehen die BigInteger's nicht aus wie Zahlen.
wie meinst du denn das?
willst du irgendwelche objekte gleich beim start des programms haben
oder dass 'alles' ein objekt ist, auch einfache ganzzahlen?Ich will meine Objekte dort haben, wo ich sie benötige - und ich will mich nicht darum kümmern müssen, ob sich hinter einer Variablen jetzt ein built-in oder ein Objekt versteckt. Und da wäre es schon gut, wenn man alles gleich behandeln könnte (inklusive Ganzzahlen).
-
Gut es ich nicht ganz so einfach da die Klassen konstante Werte halten
Gruß Baracke
-
Gregor schrieb:
CStoll schrieb:
Erzähl mehr. Hat die String-Klasse tatsächlich überladene Operatoren? Und wenn ja, wie wurde das erreicht?
Auf dem einfachsten Weg: Per Sprachdefinition.
Der Compiler wandelt das dann in entsprechende Methodenaufrufe um.Und warum werden einige Datentypen da wieder gesondert behandelt? Ich verlange Gleichberechtigung.
-
Baracke_ schrieb:
Nicht nur bei "String", es gibt (soweit ich weiss) für jeden primitiven Datentyp eine Wrapperklasse ala Integer für ints, Double für Double usw.
Diese Klassen (und auch nur diesen!) wurde eine Operaterüberladung verpasst, sprich man kann mit ihnen rechnen als ob es primitivie Datentypen wären.
Die Klassen gibt es, aber kein Operator-Overloading für diese Klassen. Stattdessen passiert da etwas anderes. Auto(un)boxing. Bei Bedarf wird aus einem int mittels Integer.valueOf(myInt) ein Integer generiert. Und bei Bedarf wird auch mittels Integer.intValue() aus einem Integer ein int extrahiert. Davon kriegt der Programmierer nicht direkt etwas mit. Er kann halt nur in diversen Fällen ein int wie ein Integer verwenden und andersherum.
-
CStoll schrieb:
Ich verlange Gleichberechtigung.
Java hat nichts mit Idealismus zu tun. Habe ich doch schon gesagt: Es geht mehr um Pragmatismus.
-
Gut Auto(un)boxing, doch wo ist der unterschied zum Operatorüberladen mal abgesehen das es in der VM implementiert? Oder wird es schon zu Erstellungszeit ausgetauscht wie Markos in C++?
Gruß Baracke
-
Gregor schrieb:
Simon2 schrieb:
Mal aus Interesse: Wie ist denn java.lang.BigInteger geschrieben ? Können die mehr als der normale Javaprogrammierer ?
Ganz normale Javaklasse. ...
Und wie haben die das gemacht ? (Weil CStolls Fragen ja konzeptioneller Natur und durchaus interessant sind)
Gruß,
Simon2.