NULL
-
Ist ja alles richtig, aber als du dann das erste mal was gesehen hast wie 1<<30, was hast du dann gedacht? Da geht eine 30 in die 1 rein?
-
Und beim Thema shift-operatoren fandest du es auch total einleuchtend? Immerhin geht hier ja die 8 nicht in die 1 rein: 1<<8
-
tfa schrieb:
Ist ja alles richtig, aber als du dann das erste mal was gesehen hast wie 1<<30, was hast du dann gedacht? Da geht eine 30 in die 1 rein?
Es war sonnenklar, weil in dem Buch drin stand, das man damit Zahlen shiften kann. Und? Vielleicht bin ich auch nur zu doof, um das nicht zu verstehen.
C++ ist halt nichts für Schlauberger.
Aber im Ernst: C++ hat eine kontextabhängige Syntax. Das solle man schon mittlerweile mitbekommen haben.
-
Shade Of Mine schrieb:
operator überladung verhindert zweideutigkeiten. deshalb ist sie gut.
schon klar, deshalb kann man auch >> und << wahlweise als shift oder als stream-i/o operator benutzen.
supertux schrieb:
als ich das erste Mal je C++ Code sah (hello world), war meine erste Frage: "hä? link shift mit einem String?"
frag' einen C-programmierer, was a<<b macht und er wird dir sagen 'nichts, weil die zuweisung fehlt'. wenn du die selbe frage an C++ programmierer richtest, würdest du wahrscheinlich so viele verschiedene antworten bekommen, wie du leute fragst.
Artchi schrieb:
Du warst aber nur verwirrt, weil du den Shift-Operator aus einer anderen Sprache (wohl C) kannstest. Aber mit dieser Voraussetzung sollte man an eine neue Sprache nicht rangehen.
und du warst etwas später verwirrt, als du bemerktest, dass es den selben shift-op auch in C++ gibt, ne?
-
Badestrand schrieb:
Freigegeben wird alles automatisch, beim Fehler fliegt 'ne Exception. Ich hab bis jetzt noch nie Operator-Überladung gesehen, die sich nicht intuitiv verhält ("do as the ints do").
Seit wann hat C++ einen anstaendigen GC? Und ein schlechtes Sprachfaeture (C++ exceptions) mit einem anderen zu kombinieren (op. ueberladung) kommen auch nur C++ler auf die Idee. Bis jetzt gibt es immer noch keinen einiges Beispiel fuer sinnvolle op.uberladung.
Nur ist das halt alles sehr kurzsichtig. denn wenn + "add" heisst und * "multiply" dann sind das ganz normale funktionen mit einem ganz bestimmten verhalten. gerade wenn man überladung nicht hat: was macht folgender code:
c=a.add(b);
ändert sich a oder ändert es sich nicht?
c = a + b;
ändert sich a oder ändert es sich nicht? - In jeder anderen Sprache wuerde ich sagen, nein, in C++: Wer weis. Um Klarheit zu verschaffen muss ich mir die Dokumentation (wie bei jeder anderen Sprache auch) anschauen. Klar, der op+ sollte man in C++ alsconst X operator+(X const& lhs, X const& rhs);
definieren, aber ist es die Regel? Und wenn die def. Zufaellig mal den Regeln erfolgt, gibt es immer noch const_cast oder andere Tricks.
Nicht nur das sich die Def. der Operatoren unterscheiden kann, man kann sogar die Def. der gleichen Operatoren+Zuweisung veraendern. Wer garantiert mir das +,-,* und / sind genauso wie +=, -=, *= und /= verhalten?
Das viel gepriesene
Matrix a, b, c; c = a + b; // anstelle von c.add(a, b);
Was passiert wenn es schief geht? Eine Art "Fehler-Matrix" zurueck zugeben? Oder eine exception zu werfen? Eine add() Funktion koennte einfach boolean zurueck geben.
Nichtmal die C++ FAQ bringt gute Beispiele fuer op.uberladung.
http://www.parashift.com/c++-faq-lite/operator-overloading.html#faq-13.3* myString + yourString might concatenate two std::string objects
* myDate++ might increment a Date object
* a * b might multiply two Number objects
* a *might access an element of an Array object
* x = p might dereference a "smart pointer" that "points" to a disk record — it could seek to the location on disk where p "points" and return the appropriate record into xdir + "/" + file
das funktioniert wenn [i]dir* ein std::string und wenn file ein char* ist, aber nicht mehr wenn dir ein char* ist und file ein std::string. Ich sag nur
std::ifstream in((std::string(dir) + "/" + file).c_str())
- myDate++, was soll das? Plus ein Jahr, ein Monat, oder ein Tag? Wenn myDate++ um Tage erhoeht, wieso ist dann myDate nicht einfach ein Integer.
usw.
- myDate++, was soll das? Plus ein Jahr, ein Monat, oder ein Tag? Wenn myDate++ um Tage erhoeht, wieso ist dann myDate nicht einfach ein Integer.
-
DEvent schrieb:
c = a + b;
ändert sich a oder ändert es sich nicht? - In jeder anderen Sprache wuerde ich sagen, nein, in C++: Wer weis.Nein. In C++ ändert sich a genausowenig wie in jeder anderen sprache.
nur weil es die möglichkeit gibt das getSize() alle Elemente löscht, erwartest du es nicht, oder?
Wer garantiert mir das +,-,* und / sind genauso wie +=, -=, *= und /= verhalten?
der selbe der die garantiert dass list.clear() die liste löscht und list.getIterator() die liste nicht löscht - der gesunde menschenverstand.
warum willst du operatoren anders behandeln als funktionen?
Was passiert wenn es schief geht? Eine Art "Fehler-Matrix" zurueck zugeben? Oder eine exception zu werfen? Eine add() Funktion koennte einfach boolean zurueck geben.
selbes problem bei
a.add(b);die richtige antwort ist bei matrizen: compile error.
oder wenn nicht anders geht: runtime error.- myDate++, was soll das? Plus ein Jahr, ein Monat, oder ein Tag? Wenn myDate++ um Tage erhoeht, wieso ist dann myDate nicht einfach ein Integer.
usw.
das selbe wie myDate.inc();
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.
- myDate++, was soll das? Plus ein Jahr, ein Monat, oder ein Tag? Wenn myDate++ um Tage erhoeht, wieso ist dann myDate nicht einfach ein Integer.
-
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.
-
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).
-
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 jetztGrüssli
-
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.
-
+' 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.
-
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.
-
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)"
-
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.
-
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.
-
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
-
+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 fetchDass 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.
-
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.
-
Das heißt es kommt bei dieser Operation also als Ergebnis sogar 27 raus?
-
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?