Hi In c# funktioniert diese Zeile: sy = y = y + 1; Diese aber nicht: sy = y++; sy bleibt 0. Hat y++ kein Rückgabewert?
Bei y++ wird der Wert y zurückgegeben und danach y um 1 erhöht. Bei ++y wird y um 1 erhöht und das Ergebnis zurückgegeben. Das ++y b.z.w. y++ entscheidet über den Zeitpunkt der Erhöhung des Wertes von y. Gruß JensM
y++ liefert den Wert zurück, den y vor der Inkrementierung hatte.
Damals in Normal-C würde das so gegangen sein denke ich sy = ++y; y++ gibt erst y zurück und inkrementiert sich anschliessend ...
mar IO schrieb: > siehe auch > > http://openbook.galileocomputing.de/c_von_a_bis_z/... Der Link ist allerdings für C und nicht für C#, richtiger wäre z.B.: http://msdn.microsoft.com/en-us/library/36x43w8w.aspx
Tja, ja, die unfassbar unerträglichen Leiden der "C"-Jünger. "Mit einer richtigen Programmiersprache wäre das nicht passiert!" ;-) Gruß, Rüdiger
Samuel K. schrieb: > In c# funktioniert diese Zeile: > ... > Diese aber nicht: Nachdem deine eigentliche Frage schon beantwortet wurde: Verabschiede Dich von dem Gedanken, dass eine Zeile nicht funktioniert. Gewöhne dich an den Gedanken, dass eine Zeile etwas anderes bedeutet, als Du erwartest.
Samuel K. schrieb: > sy = y = y + 1; > > > sy = y++; Beides sollte man meiner Meinung nach unterlassen, wenn man lesbare, wartbare Programme schreiben will. Eine Zuweisung pro zeile ist völlig ausreichend. Eine Zuweisung mit einem Rückgabewert auszustatten ist meiner Meinung nach ein Designfehler, der sich leider durch alle c-oiden Programmiersprachen zieht.
JensM schrieb: > Das ++y b.z.w. y++ entscheidet über den Zeitpunkt der Erhöhung des > Wertes von y. Ich dachte, dass das bei einer Zuweisung keine Rolle spielt, also y auf jedem Fall vor dem = erhöht wird. Wieder was dazugelernt. Danke für die Antworten!
So, da der TO befriedigt ist: Dann nennt doch mal bitte eure ganzen tollen supersprachen, die solche "Fehler" nicht erlaube und ähnliche Praxistauglichkeit und Verbreitung besitzen!
Weite Verbreitung ist kein Indiz von "Brauchbarkeit" bzw. einer Eignung für einen bestimmten Zweck. Unter Milliarden Fliegen z.B. ist das Verzehren von Sch...e recht weit verbreitet. Die somit (unter Fliegen, von denen es wohl deutlich mehr als Menschen gibt?!) breit angelegte Akzeptanz macht Sch...e jedoch noch lange nicht zu einer Delikatesse... Praxistauglichkeit ist auch so eine Sache bei C und ähnlichen Sprachen, da das vom TO beschriebene Verhalten und andere ähnliche "kleine Absonderlichkeiten" eben immer wieder - gerade bei Einsteigern - für Ratlosigkeit sorgen. Von "Supersprachen" zu sprechen halte ich für Unfug, es gibt bestenfalls Programmiersprachen, welche aufgrund Ihres Designs und Abstraktionsgrades bestimmte Fehler, Unklarheiten oder nicht-Eindeutigkeiten ausschließen. Bestimmend ist aber letztlich noch immer die "Qualität" bzw. Qualifikation des Programmierers im Umgang mit "seinem" Werkzeug, d.h. Programmiersprache. Und: Echte Programmierer codieren mit Diodenmatrix und Lötkolben! In diesem Sinne... Joachim
Anheizer schrieb: > Dann nennt doch mal bitte eure ganzen tollen supersprachen, die solche > "Fehler" nicht erlaube und ähnliche Praxistauglichkeit und Verbreitung > besitzen! das sind meiner Meinung nach keine Fehler. Ich finde es gut Sachen wir array[i++]++ schreiben zu können.
Samuel K. schrieb: > as sind meiner Meinung nach keine Fehler. Ich finde es gut Sachen wir > array[i++]++ schreiben zu können. und warum? weil das Programm 4 (windows-Zeilenende) Byte weniger auf der Festplatte belegt als
1 | array[i]++; |
2 | ++i |
edit: oder kommst du dir da professioneller vor, wenn du jedes Syntax-Zuckerkrümelchen kennst und benutzt?
Vlad Tepesch schrieb: > Eine Zuweisung mit einem Rückgabewert auszustatten ist > meiner Meinung nach ein Designfehler Wohl dosiert kann es schon sinnvoll sein:
1 | BufferedReader reader = ...; |
2 | String line; |
3 | while ((line = reader.readLine()) != null) { |
4 | System.out.println(line); |
5 | }
|
Auf alle anderen Weisen hat man immer das Problem, dass man einmal line sinnvoll initialisieren muss (meisst durch ein weiteres ReadLine), und innerhalb der Schleife das ReadLine vergessen kann oder an der falschen Stelle aufruft. Vergisst man das hier, erkennt das der Compiler, außerdem wird man im weiterem Verlauf gewarnt, dass line nur noch null sein kann, was mit einer Initialen Initialisierung möglicherweise nicht mehr erkannt wird.
joachim lenz schrieb: > breit angelegte Akzeptanz macht Sch...e jedoch noch > lange nicht zu einer Delikatesse... Doch, für Fliegen offensichtlich schon. Du lieferst ein schönes Beispiel für einen fehlgeschlagenen Versuch, etwas schlecht zu reden.
Vlad Tepesch schrieb: > und warum? > weil das Programm 4 (windows-Zeilenende) Byte weniger auf der Festplatte > belegt als Es geht um die Zeilen. Bei Seitemlangem Code können weniger Zeilen den Code schon lesbarer machen. c = a---++b Wer bietet mehr?
Samuel K. schrieb: > c = a---++b hier ist ja aber sofort klar, was passiert a-- - ++b bei b= a+++c könnte es a + ++c oder a++ + c heißen hier muss man definiv länger überlegen
Vlad Tepesch schrieb: > könnte es > a + ++c > oder > a++ + c heißen > hier muss man definiv länger überlegen Der Compiler nimmt natürlich die erste Variante, da er von links nach rechts auswertet. Deswegen blickt er das auch nicht a+++++c, obwohl es eindeutig ist. a+++(++c) frisst er.
Samuel K. schrieb: > Der Compiler nimmt natürlich die erste Variante, da er von links nach > rechts auswertet. es gibt sowas wie operator präzedenz. da ++ höherrangig ist als +, nimmt er das auch zuerst
Vlad Tepesch schrieb: > es gibt sowas wie operator präzedenz. > da ++ höherrangig ist als +, nimmt er das auch zuerst Ich weiß, aber a++ und ++a ist gleichwertig. Und a+++++b versteht er trotzdem nicht.
Samuel K. schrieb: > Ich finde es gut Sachen wir > array[i++]++ schreiben zu können. Du kannst auch "array{i plus plus> + 1" schreiben, das ist auch kein C...
Da habe ich mich verguckt, es ist wohl doch legal. Trotzdem völliger Bananencode. :-)
Samuel K. schrieb: > Ich weiß, aber a++ und ++a ist gleichwertig. Nein, ist es nicht. Postfix bindet stärker als Prefix.
Stefan Ernst schrieb: > Nein, ist es nicht. Postfix bindet stärker als Prefix. Warum erkkent der compiler das dann nicht? a+++++b eigentlich müsste er das doch (a++)+(++b) erkennen? PS: es heißt Präfix (vom lat. prä = vor)
Dieses Spiel hat nicht allein mit dem Vorrang der Operatoren zu tun, sondern auch mit der Zerlegung des Quelltextes in die syntaktischen Sprachelemente (Tokens), die stets die längste mögliche Zeichenfolge bevorzugt. Deshalb wird +++++ zu ++ ++ + noch bevor der Parser das überhaupt zu Gesicht bekommt. ---++ wird jedoch zu -- - ++ weil es -+ als Token nicht gibt. Da aber a++ keine lvalue ist (sowas darf links von "=" stehen), sondern eine rvalue (rechts), ist (a++)++ nicht zulässig. Dieses Problem zeigt sich auch bei C++, wo streckenweise mit <xxx> geklammert wird und leerzeichenfreie Verschachtelungen wie <xxx<yyy>> am Verständnis der schliessenden Klammern als Shift-Operator scheitern.
Ist das Verhalten des Parsers denn durch den Standard geregelt?
Samuel K. schrieb: > Warum erkkent der compiler das dann nicht? > a+++++b > eigentlich müsste er das doch (a++)+(++b) erkennen? Nein, denn Postfix bindet auch stärker als +, also wird daraus ((a++)++)+b, und das funktioniert nicht. > PS: es heißt Präfix (vom lat. prä = vor) Ja, und im Englischen heißt es Prefix. Willst du mir jetzt etwa vorwerfen, zu viele englische Begriffe zu verwenden?
mh schrieb: > Ist das Verhalten des Parsers denn durch den Standard geregelt? Ja. C99: "If the input stream has been parsed into preprocessing tokens up to a given character, the next preprocessing token is the longest sequence of characters that could constitute a preprocessing token." Lass dich vom Begriff "preprocessing" nicht stören. Der Fall wird dort sogar extra aufgeführt: "EXAMPLE 2 The program fragment x+++++y is parsed as x ++ ++ + y, which violates a constraint on increment operators, even though the parse x ++ + ++ y might yield a correct expression."
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.