NULL

[DEvent]

Shade Of Mine schrieb:

operatoren sind funktionen - behandle sie bitte so. wenn ich myDate.inc() implementiere bin ich ein vollkoffer. wenn ich myDate++ implementiere auch. Ich sehe einfach keinen unterschied zwischen diesen beiden sachen.

Genauso ist es. Aber anderes zu Funktionen haben Benutzer eine vorgefasste Meinung ueber Operatoren. Deswegen erhoeht es die Lesbarkeit nicht wenn man Op. ueberlaed. Es ist genauso sinnfrei einen ^-Operator als pow(x, y) zu missbrauchen wie die << und >> Operatoren fuer Streams.

[JustAnotherNoob]

Seit wann hat C++ einen anstaendigen GC?

warum willst du bei Operatorenüberladung dynamisch allokieren? oO

Aber anderes zu Funktionen haben Benutzer eine vorgefasste Meinung ueber Operatoren.

Ich hab die Meinung zu Funktionen, die der Funktionsname her gibt. add addiert für mich genau wie +. Dass Operatoren manchmal mehr als eine Bedeutung haben, was man bei Funktionen differenzierter machen könnte kann man kritisieren, aber das scheinen die Javaentwickler nicht gemeint zu haben, denn der + Operator funktioniert auch bei Strings(Warum auch immer, schließlich braucht man es nicht, da Strings Objekte sind und man ihnen auch entsprechende Methoden hätte spendieren können. Lesbarkeit? Warum sollen nur Strings das Privileg haben... das nenne ich inkonsequent).

[Dravere]

Zum Unterthema ob Shiftoperatoren intuitiv sind für Streams. Mein Buch hat zuerst die normalen Shift für Zahlen behandelt, kannte sie auch schon ein wenig von anderen Sprachen, und danach die Streams. Ich fand es ehrlich gesagt äussert einleuchtend.
Wieso? Hat einer von euch schon mal "to shift" übersetzt? Etwas schieben, verschieben. Perfekt, man schiebt den Text oder was auch immer in den Stream rein. Besser und verständlicher kann es ja nicht sein. Und auch die Richtung stimmt, << für rein in den Stream und >> für raus aus dem Stream.

@Sonstige Kritiken,
Tja, C++ setzt halt vernünftigen Menschenverstand voraus. Ich stimme euch zu, dass viele Menschen keinen vernünftigen Menschenverstand haben, aber für viele von denen ist ja C++ auch viel zu schwer zum Erlernen. Die gehen dann in andere Sprachen, wie J ... eh, nein den letzten Satz vergessen wir jetzt

Grüssli

[+fricky]

JustAnotherNoob schrieb:

Dass Operatoren manchmal mehr als eine Bedeutung haben, was man bei Funktionen differenzierter machen könnte kann man kritisieren, aber das scheinen die Javaentwickler nicht gemeint zu haben...

doch, genau das haben sie gemeint.

...denn der + Operator funktioniert auch bei Strings(Warum auch immer...

'+' funktioniert auch für char, long, double usw. d.h. es gibt schon einige 'hartverdrahtete' überladungen, woran keiner herumbasteln kann. daher kannst du immer sicher sein: wenn irgendwo im code ein '+' auftaucht, ist es entweder eine numerische addition, oder eine stringverkettung (oder bestandteil einer zeichen- oder stringkonstanten, aber das lassen wir mal aussen vor).

Dravere schrieb:

Tja, C++ setzt halt vernünftigen Menschenverstand voraus.

menschenverstand vielleicht, aber vernunft ist eher hinderlich. wenn du versuchst, aus dir bekannten c++ fakten andere zu schlussfolgern, haste schon verloren.

[JustAnotherNoob]

+' funktioniert auch für char, long, double usw. d.h. es gibt schon einige 'hartverdrahtete' überladungen, woran keiner herumbasteln kann. daher kannst du immer sicher sein: wenn irgendwo im code ein '+' auftaucht, ist es entweder eine numerische addition, oder eine stringverkettung (oder bestandteil einer zeichen- oder stringkonstanten, aber das lassen wir mal aussen vor).

entweder-oder, 2 völlig verschiedene Operationen mit dem selben Namen, also genau das was hier:

doch, genau das haben sie gemeint.

so absolut böse sein soll.
nichts anderes ist das.

Also entweder haben sie überhaupt nicht drüber nachgedacht, oder sie haben sich gedacht, dass es doch sinnvoll sein könnte, den + Operator für Strings zu überladen, andere Objekte sollen das aus unerfindlichen Gründen aber nicht können(Kann ja auch gar nicht sein, dass das was einmal sinnvoll ist, ein ander mal auch noch sinnvoll ist, das geht nit).
So oder so, durchdacht ist das nicht, Logik sucht man im Sprachaufbau Javas vergeblich.

[Shade Of Mine]

DEvent schrieb:

Genauso ist es. Aber anderes zu Funktionen haben Benutzer eine vorgefasste Meinung ueber Operatoren. Deswegen erhoeht es die Lesbarkeit nicht wenn man Op. ueberlaed. Es ist genauso sinnfrei einen ^-Operator als pow(x, y) zu missbrauchen wie die << und >> Operatoren fuer Streams.

Nur hat das nix mit Operatoren zu tun.
Wenn du statt pow() die funktion hugo() nennst, ist es das selbe.

Diese gefestigte "Meinung" über Operatoren ist ja gerade der Vorteil.

c=a+b;

komplett klar was das macht. Keine zweideutigkeit vorhanden.
c=a.add(b);
nicht mehr so klar.

[u_ser-l]

Die Trennung zwischen Operatoren und Methoden ist in C++ ohnehin etwas künstlich und führt zu starken syntaktischen Einschränkungen. In anderen OO-Sprachen wie z.B. smalltalk ist "+" nichts Anderes als eine Nachricht (mit einer zweiten Zahl als Parameter), die an Zahlen gesendet wird: 4 + 5 im Sinne von "4.add(5)"

[+fricky]

JustAnotherNoob schrieb:

...entweder-oder, 2 völlig verschiedene Operationen mit dem selben Namen...
[...]
Also entweder haben sie überhaupt nicht drüber nachgedacht, oder sie haben sich gedacht, dass es doch sinnvoll sein könnte, den + Operator für Strings zu überladen...

so hart wie du denkst, ist der bruch nicht. im prinzip gibt es 3 feste überladungen: ein '+' für ganzzahlen, ein '+' für fliesskommazahlen und ein '+' für strings. ein '+' für booleans z.b. gibt es nicht, für referenzen auch nicht. das verhalten aller 'plusse' sind dem programmierer bekannt und keiner kann es ändern. das macht die sache extrem zuverlässig und sorgt für gut lesbaren und verständlichen code. in C++ z.b. nehmen viele lieber ++x statt x++ (obwohl x++ besser passen würde), weil der post-increment eventuell ein überladener operator sein könnte, der 'ne überflüssige und potentiell lahme kopieroperation macht. solche zweifel kommen bei operatoren, deren verhalten unveränderlich ist, gar nicht erst auf.

[JustAnotherNoob]

In anderen OO-Sprachen wie z.B. smalltalk ist "+" nichts Anderes als eine Nachricht (mit einer zweiten Zahl als Parameter), die an Zahlen gesendet wird: 4 + 5 im Sinne von "4.add(5)"

Infixnotation ist praktisch aber wie wird das mit der Operatorenpriorität geregelt?
In Scala kann man auch jede Funktion infix schreiben, was etwas störend ist sind die vielen Regeln und Sonderregeln zur Priorität, Assoziativität u.s.w.... Wie sieht das in Smalltalk aus?

so hart wie du denkst, ist der bruch nicht.

Es ist ein Bruch und das ist ausreichend.
Entweder man sagt a oder b, aber so beweist Java doch nur, dass das eigene Konzept schwachsinnig ist.
Entweder man sagt, es ist nie sinnvoll, oder man sagt es kann sinnvoll sein, Strings beweisen letzteres und das dann einzuschrenken ist unsinnig. Den Styleguide, dass Operatorenüberladung wenn möglich zu vermeiden ist kannst du im Nachhinein immer noch schreiben.

[Dravere]

@fricky,

Was ist das denn für eine Argumentation? Dir ist schon klar, dass das absolut normale Verhalten von x++ ist, dass vom alten Objekt eine Kopie zurückgegeben wird. Das ist sogar in Java der Fall. Daher passt eigentlich auch x++ nicht besser, sondern ++x. Man will ja kein altes Objekt haben, sondern x soll nur inkrementiert werden. Auch für einen Javaprogrammierer ist das passender.

Das hat nicht mit der Möglichkeit zu tun, dass der Operator womöglich überladen sein könnte. Das ist das normale unveränderliche Verhalten des Postinkrements.

Menschenverstand ...

Grüssli

[Shade Of Mine]

+fricky schrieb:

solche zweifel kommen bei operatoren, deren verhalten unveränderlich ist, gar nicht erst auf.

Gibts in C++ auch nicht.
x++ ist immer fetch and increment
und
++x ist immer increment and fetch

Dass es jetzt den spezialfall gibt, dass x++ genauso schnell sein kann wie ++x ist eher ein technisches detail. denn x++ ist langsamer als ++x (es sei denn der compiler kann das irgendwie optimieren).

Ist in Java und C genauso.

[Bashar]

JustAnotherNoob schrieb:

In anderen OO-Sprachen wie z.B. smalltalk ist "+" nichts Anderes als eine Nachricht (mit einer zweiten Zahl als Parameter), die an Zahlen gesendet wird: 4 + 5 im Sinne von "4.add(5)"

Infixnotation ist praktisch aber wie wird das mit der Operatorenpriorität geregelt?

Gar nicht, das sind wirklich einfach Nachrichten an ein Objekt. 4 + 5 * 3 heißt also: Sende + an 4 und übergib 5, sende * an das Ergebnisobjekt und übergib 3.

[JustAnotherNoob]

Das heißt es kommt bei dieser Operation also als Ergebnis sogar 27 raus?

[+fricky]

JustAnotherNoob schrieb:

so hart wie du denkst, ist der bruch nicht.

Es ist ein Bruch und das ist ausreichend.
Entweder man sagt a oder b, aber so beweist Java doch nur, dass das eigene Konzept schwachsinnig ist.

der bruch ist, dass '+' in den meisten fällen 'ne arithmetische operation, in einem fall ein zusammenkleben von zeichen ist. nun ist aber java.lang.String mit seinem '+' sogar in der sprachdefinition verankert, was das ganze halb so wild macht. wie schon gesagt: kein mensch kann sich selbst einen eigenen +-operator basteln, der irgendwelche seltsamen dinge macht. und das ist das entscheidende.

Dravere schrieb:

Was ist das denn für eine Argumentation? Dir ist schon klar, dass das absolut normale Verhalten von x++ ist, dass vom alten Objekt eine Kopie zurückgegeben wird.

wer sagt das? wenn ich keine kopie brauche, wird auch nix zurückgegeben. aber in C++ ist das vermutlich anders.

Shade Of Mine schrieb:

...denn x++ ist langsamer als ++x (es sei denn der compiler kann das irgendwie optimieren).
Ist in Java und C genauso.

hast du'n beispiel, wo postinkrement in Java (oder C) langsamer ist, als preinkrement?

[JustAnotherNoob]

nun ist aber java.lang.String mit seinem '+' sogar in der sprachdefinition verankert, was das ganze halb so wild macht. wie schon gesagt: kein mensch kann sich selbst einen eigenen +-operator basteln, der irgendwelche seltsamen dinge macht. und das ist das entscheidende.

Nochmal...
entweder es kann sinnvoll sein, oder eben nicht...
ist es manchmal sinnvoll -> Operatorenüberladung
ist es nicht sinnvoll -> Keine Operatorenüberladung

Dass es in Java als Ausnahmefall definiert wird(In der Sprachdefinition verankert ist) macht es nur zu einem Designfehler. Java ist eben das Französisch unter den Programmiersprachen.

wer sagt das? wenn ich keine kopie brauche, wird auch nix zurückgegeben. aber in C++ ist das vermutlich anders.

Nö, C++ Compiler optimieren ebenso, mehr ist das nicht.

[+fricky]

JustAnotherNoob schrieb:

ist es manchmal sinnvoll -> Operatorenüberladung

und genau das ist falsch. 'manchmal' reicht nun mal als grund nicht aus.

[Dravere]

+fricky schrieb:

Dravere schrieb:

Was ist das denn für eine Argumentation? Dir ist schon klar, dass das absolut normale Verhalten von x++ ist, dass vom alten Objekt eine Kopie zurückgegeben wird.

wer sagt das? wenn ich keine kopie brauche, wird auch nix zurückgegeben. aber in C++ ist das vermutlich anders.

Zum Beispiel der C oder der Java Standard. Lies es dort nach!
Dass der Kompiler dies optimieren kann, ist etwas ganz anderes und gehört nicht zur Sprache dazu. Auch ein C++ Kompiler kann sowas optimieren.

Ein vernünftiger Programmierer wird allerdings nicht der Postinkrement aufrufen, damit der Kompiler bei der Optimierung dann ein Preinkrement daraus macht. Wieso nicht gleich ein Preinkrement hinsetzen?

Grüssli

[JustAnotherNoob]

und genau das ist falsch. 'manchmal' reicht nun mal als grund nicht aus.

liest du ab und zu auch was ich schreibe?
Ich meine da waren ganz klar 2 Möglichkeiten..

edit:
und btw. sehe ich das vollkommen anders. Manchmal reicht völlig aus. Weil es eben Momente gibt in denen es sinnvoll ist und es Momente gibt in denen es nicht sinnvoll ist.
Wenn du dir nicht zutraust die Situation richtig einzuschätzen dann kannst dus auch ganz bleiben lassen, selbst dafür musst du dann nicht Java nehmen.

Java Standard

Sowas gibts doch gar nicht?
Die Sprachspezifikation meinst du wohl eher.

[+fricky]

Dravere schrieb:

Ein vernünftiger Programmierer wird allerdings nicht der Postinkrement aufrufen, damit der Kompiler bei der Optimierung dann ein Preinkrement daraus macht. Wieso nicht gleich ein Preinkrement hinsetzen?

x++;     // x lesen, hochzählen, x zuweisen
++x;     // x lesen, hochzählen, x zuweisen
y = x++; // x lesen, y zuweisen, hochzählen, x zuweisen
y = ++x; // x lesen, hochzählen, x zuweisen, y zuweisen

^^wo siehst du da 'nen unterschied? x++ bzw. ++x brauchen jeweils 3 bzw. 4 operationen. wieso sollte ++x schneller sein als x++. unter C++ mag es ja so sein, aber normal ist das nicht.

[Shade Of Mine]

+fricky schrieb:

hast du'n beispiel, wo postinkrement in Java (oder C) langsamer ist, als preinkrement?

Klar.

int i=0;
++i;

Nur weil dein java compiler das optimieren kann heisst es ja nicht dass es meiner können muss.

Die Sache ist halt die, dass es sehr sehr leicht optimierbar ist - keine Frage. Aber die Semantik ist komplett gleich. Ich hab übrigens nen C compiler der das nicht optimieren kann... Wenn für ++x immer x++ verwendet wird, ist das nunmal ein Fehler des programmierers. Kein großer Fehler, aber ein Fehler. Und in gewissen Situationen bestraft C++ nun diesen Fehler. Ich sehe das kein Problem.

und genau das ist falsch. 'manchmal' reicht nun mal als grund nicht aus.

Dir ist schon bewusst dass alle Sprachfeatures nur manchmal gebraucht werden. zB wozu brauch ich for und do while in C? vollkommen unnötig weil redundant.
operatoren überladung fügt dafür ein neues konzept hinzu. ein neues konzept kann definitions bedingt nicht redundant sein.

natürlich können wir jetzt generell allen sprachen alle features wegdiskutieren. wozu zB int, short und long? reicht nicht double für alles?

wozu funktionen wenn wir goto haben...

Ach fricky, bemüh dich doch wenigstens