c++ vs. java... was hat zukunft
-
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.
-
generell kann man sagen das java nicht vollkommen generisch ist, da man immer zwischen primitiven und objektreferenzen unterscheiden muss, und diese unterschiedlich behandeln muss, da es keine möglichkeit der gleichbehandelung gibt
-
Gregor schrieb:
CStoll schrieb:
Ich verlange Gleichberechtigung.
Java hat nichts mit Idealismus zu tun. Habe ich doch schon gesagt: Es geht mehr um Pragmatismus.
Und schon beim Pragmatismus hapert es. Vielleicht bin ich ja zu tief im C++ Template-Denken verankert, aber für mich definiert sich ein Objekt nicht nur dadurch, was es kann, sondern auch wie du dieses Können abrufen kannst. Und wenn die selbe Operation (z.B. Addition) bei verschiedenen Typen völlig anders angesprochen werden muß oder die Wirkung einer Anweisung (z.B. das recht primitive 'x=y;') davon abhängt, welche Typen man verwendet, läuft das zumindest meinem Konzept zuwider.
-
schon aus smalltalk dürften protokolle bekannt sein
alles was sich aufführt wie ein integer wird wohl einer sein
in java hat man eher - oh alles was sich aufführt wie eine primitive geht mir auf die nerfen weils unvereinbar mit anderen objekten ist
-
Also wenn ich Echtzeitanwendungen brauche dann ist mir ein nichtdeterministischer GC einfach im Weg.
Um also mal zum eigentlichen Thema zurückzukommen ( irgendwie driftet das hier in Richtung "meine Syntax ist besser als deine, weil ich BigInts per operatoroverloading für Dummys benutzbar machen kann" ab):
Es wird für beide ( und andere ) Programmiersprachen eine Zukunft geben, solange es unterschiedliche Anforderungen an Software gibt.
Verge
-
Simon2 schrieb:
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)
du kannst dir den source code anschauen, es sind keine versteckten tricks darin.
der ist aber etwas länglich um ihn hier zu posten...
oder soll ich mal?
-
pale dog schrieb:
...
der ist aber etwas länglich um ihn hier zu posten...
oder soll ich mal?Neee, aber vllt. Kannst Du CStoll ja seine Fragen zu dem Thema anhand des Quellcodes beantworten.
Gruß,
Simon2.
-
Simon2 schrieb:
pale dog schrieb:
...
der ist aber etwas länglich um ihn hier zu posten...
oder soll ich mal?Neee, aber vllt. Kannst Du CStoll ja seine Fragen zu dem Thema anhand des Quellcodes beantworten.
die frage: 'Wie ist denn java.lang.BigInteger geschrieben ? Können die mehr als der normale Javaprogrammierer ?'
kann man beantworten mit: 'normale javaprogrammierer hätten sich die klasse selber schreiben können'
-
Und hätten sich normale Java-Programmierer auch die Klasse String oder Int selber schreiben können?