Compiler liegt mal wieder falsch!
-
EOP schrieb:
[...]
Was spricht dagegen, sich mit dem Thema zu beschäftigen anstatt mit irgendwelchen Stilfragen?
Der Threadersteller meinte, einen Compilerbug gefunden zu haben. Für den Compiler aus VS 2012 kann ich das nicht bestätigen, der verhält sich so, wie es die Spezifikation verlangt.
-
audacia schrieb:
Der Threadersteller meinte, einen Compilerbug gefunden zu haben. Für den Compiler aus VS 2012 kann ich das nicht bestätigen, der verhält sich so, wie es die Spezifikation verlangt.
Hab hier schön öfters Leute gesehen, die meinten schlauer als der Compiler zu sein. Lagen alle falsch.
-
EOP schrieb:
audacia schrieb:
Der Threadersteller meinte, einen Compilerbug gefunden zu haben. Für den Compiler aus VS 2012 kann ich das nicht bestätigen, der verhält sich so, wie es die Spezifikation verlangt.
Hab hier schön öfters Leute gesehen, die meinten schlauer als der Compiler zu sein. Lagen alle falsch.
Die Frage danach welchen Compiler er verwendet hat hat mir der OP ja nicht beantwortet.
Davon abgesehen: bei C++ kommt das schon öfter mal vor dass der Programmierer schlauer als der Compiler ist. Speziell bei Compilern wie MSVC die noch nicht so ganz "up to date" sind, und die in vielen Projekten auch noch in sehr alten Versionen verwendet werden.
Bei C# ist es aber denke ich wirklich recht selten.
-
Ich benutze Visual Studio Express.
Freitag Abend war ich wohl auch nicht mehr so konzentriert. Der Compiler wirft bei mir jetzt auch 5 und nicht 4 raus. Ich hätte aber 6 erwartet.
Wenn ich Audacia Ausführungen interpretiere, dann meint auch er das das Ergebniss der x++ Operation durch die Zuweisung überchrieben wird.
-
Visual Studio Express 2013 V12.0.31101.00 Update 4
-
audacia schrieb:
[*]"
x += 3 + x++":7.17.2 Compound assignment
[...]
An operation of the form x op= y is processed by applying binary operator overload resolution (§7.3.4) as if the operation was written x op y. Then,
• If the return type of the selected operator is implicitly convertible to the type of x, the operation is evaluated as x = x op y, except that x is evaluated only once.Also wird das ausgewertet als "
x = x + 3 + x++".Nö, "x = x + (3 + x++)".
Wobei das hier wohl keinen Unterschied macht.
Wichtig ist ja nur dass er sich den Wert von "x" schnappt bevor er anfängt "3 + x++" auszuwerten.
-
hustbaer schrieb:
audacia schrieb:
7.17.2 Compound assignment
[...]
An operation of the form x op= y is processed by applying binary operator overload resolution (§7.3.4) as if the operation was written x op y. Then,
• If the return type of the selected operator is implicitly convertible to the type of x, the operation is evaluated as x = x op y, except that x is evaluated only once.Also wird das ausgewertet als "
x = x + 3 + x++".Nö, "x = x + (3 + x++)".
Tatsächlich, du hast recht. Das ist subtil, weil durch die Zusammenfassung der RHS als
yinx = x op yimplizit gesagt wird, daßyzuerst ausgewertet werden muß (alsox = x op (y)) und nicht nachträglich noch Operatorpräzedenz und Linksassoziativität angewandt wird. Es ist klar, daß es sich so verhalten muß, denn wennyeinen Operator beinhaltet, der geringere Priorität hat als+, also etway = 2 << 3, dann mußx += 2 << 3zux = x + (2 << 3)werden und nicht zux = x + 2 << 3, wasx = (x + 2) << 3entspräche.hustbaer schrieb:
Wichtig ist ja nur dass er sich den Wert von "x" schnappt bevor er anfängt "3 + x++" auszuwerten.
Ja, zum Verstehen der 5 reicht es, das zu wissen.
-
audacia schrieb:
Es ist klar, daß es sich so verhalten muß, (...)
Ja, klar. Deswegen sind bei deinem
"x = (x + 3) + (x++)"auch gleich Alarmglocken bei mir im Kopf losgegangen. So subtil finde ich das nämlich nicht
Mit dem "wichtig ist ja nur (...)" meinte ich natürlich nur das hier diskutierte Beispiel, bei dem es eben keinen Unterschied macht. Dass es allgemein einen Unterschied macht (bzw. machen kann), und daher alles andere als egal ist, ist klar.
-
hustbaer schrieb:
So subtil finde ich das nämlich nicht
Nachts um eins vielleicht schon
-
Da bin ich erst mal richtig wach geworden.
