Frage zu increment

SeppJ

@SeppJ also ich interpretiere es jedenfalls so.

Und deswegen ist es wichtig, dass du genauer liest und genau mitdenkst. Denn das steht da nicht. Du machst einen nicht gerechtfertigten Gedankensprung von "nach der Auswertung des Postfix" zu "nach dem nächsten Sequenzpunkt".

Da der Computer immer ganz genau tut, was du ihm sagst, und nicht das, was du meinst, ist es wichtig, dass du die Regeln ganz genau liest und verstehst, und da keine eigene Interpretation rein bringst.

DirkB

@Wade1234 sagte in Frage zu increment:

also ich interpretiere es jedenfalls so

Das Problem hier ist die Zuweisung an x innerhalb des Sequence Points (der endet hier beim ; )

clang mag hier auf der rechten Seite 2+3 auswerten (da wäre x dann 4. Dann folgt die Berechnung und Zuweisung an x. Also 5

Ist aber auch egal, da es undefiniert ist.

hustbaer

@Wade1234
Postfix garantiert dass der Wert der inkrementierten/dekrementierten Variable (nicht! des gesamten Ausdrucks) vor dem Ändern der Variable ermittelt wird, und das Ändern der Variable dann danach passiert. Eine Garantie dass das Ändern der Variable noch weiter verzögert wird, z.B. bis nach dem Assignment in diesem Beispiel, gibt es nicht.

D.h. es könnte 2 als Wert ermittelt werden, dann x inkrementiert, und dann erst das Assignment x = 2 durchgeführt.

Welche weiteren Regeln es diesbezüglich noch gibt hat sich soweit ich weiss auch zumindest einmal mit C++11~17 geändert. Das sind Regeln die ich nicht auswendig kenne. Ich schreibe solchen Code nicht. Macht doch überhaupt keinen Sinn wenn man beim Code Lesen dauernd über Konstrukte stolpert wo man so esoterische Regeln kennen muss um zu verstehen ob sie überhaupt definiertes Verhalten haben. Und es ist viel zu leicht damit Mist zu bauen.

hustbaer

@DirkB Gibt es Sequence-Points in C++11 noch? Ich dachte das wurde durch anders formulierte Regeln ersetzt.

SeppJ

@hustbaer sagte in Frage zu increment:

@DirkB Gibt es Sequence-Points in C++11 noch? Ich dachte das wurde durch anders formulierte Regeln ersetzt.

Es ist jetzt anders formuliert, ja, aber es kommt aufs gleiche raus. Jetzt gibt es Aussagen darüber, welche Art von Effekten "vor" oder "nach" anderen Effekten auftreten. Da hier aber alle Effekte von der gleichen Art sind und auf dem selben Objekt arbeiten, ist das Verhalten nach wie vor undefiniert.

PS: In C++17 hat man es aber noch feiner unterteilt, da fallen manche dieser Beispiele weg. i = i++; ist jetzt wohldefiniert. i = i++ + ++i; aber nach wie vor nicht.

PPS: Der Preis dafür ist, das aus 5 Regeln nun 21 geworden sind

hustbaer

@SeppJ Danke
BTW: Was heisst "vodrukeln"?

SeppJ

@hustbaer sagte in Frage zu increment:

@SeppJ Danke
BTW: Was heisst "vodrukeln"?

Das ist so etwas wie verdräkeln, aber weniger kubunt.

hustbaer

@SeppJ Ah, verdammt. Wenn mir der Name dieser überaus geheimen Geheimsprache einfallen würde könnte ich jetzt die Regeln nachlesen.

hustbaer

@SeppJ sagte in Frage zu increment:

PPS: Der Preis dafür ist, das aus 5 Regeln nun 21 geworden sind

Naja dafür sind die aber halbwegs einfach.

SeppJ

@hustbaer sagte in Frage zu increment:

@SeppJ sagte in Frage zu increment:

PPS: Der Preis dafür ist, das aus 5 Regeln nun 21 geworden sind

Naja dafür sind die aber halbwegs einfach.

Naja. Ist so meiner Meinung nach eher so wie wenn man aus

if isalpha(c)
   prio = 1;
else if isdigit(c)
   prio = 2;

stattdessen

if c == 'a'
   prio = 1;
else if c == 'b'
   prio = 2;
// ...
else if c == 'z'
   prio = 26;
else if c == '0'
   prio = 27;
// ...

macht.

hustbaer

@SeppJ Ja verstehe schon was du meinst. Andrerseits... wer Code schreibt wo das ne Rolle spielt, der ist mMn. selbst schuld. Klar, dazu muss man wissen was evtl. problematisch werden könnte. Aber man muss nicht die ganzen Regeln kennen wo es dann doch definiert ist.

wob

Die Compiler warnen. Rant: ich halte es für einen fragwürdig, dass nicht ein Mindestset an Warnungen per default an ist bei gcc/clang. "may be undefined" -> warum kann man da nicht einen Compilefehler draus machen? Oder hat die sequence point Fehlermeldung false positives?
Wenn man den Code mal in godbolt kippt und die Compiler durchklickt, sieht man, dass ältere gcc (4.x) in der Tat 6 liefern und neuere 5. (jeweils mit -O2) zumindest.

irgendwie gibt es jetzt noch einen grund mehr, nur eine anweisung pro zeile zu machen. also man muss schon ziemlich wirr sein, wenn man diese ganzen regeln als endanwender auswendig lernt.

außerdem liefert der clang doch eine warnung und der gcc wird das auch tun (es wundert mich sowieso, warum es immer heißt "aktivier doch mal die warnungen!"; die sind nirgendwo ausgeschaltet.):

test.c:8:7: warning: multiple unsequenced modifications to 'x' [-Wunsequenced]
        x = x++;
          ~  ^


test.c:8:7: warning: multiple unsequenced modifications to 'x' [-Wunsequenced]
        x = x++ + x++;

DirkB

@Wade1234 sagte in Frage zu increment:

es wundert mich sowieso, warum es immer heißt "aktivier doch mal die warnungen!"; die sind nirgendwo ausgeschaltet.):

Alle sind nicht aktiviert, selbst bei -Wall nicht.
Und bei VS ist i. A. auch nicht der höchste Warnlevel aktiv.

@wob sagte in Frage zu increment:

warum kann man da nicht einen Compilefehler draus machen?

-Werror

ja aber sie sind auch nicht komplett aus

DirkB

@Wade1234 Es ist (wegen C-Historie) kein Fehler.

Ein gutes Programm compiliert ohne Warnungen.
Darum musst du dir auch alle Warnungen ansehen, so wie du es bei Fehlern auch machst.

Wenn du es nicht machst, bleibt es dein Problem.
Ein Error zwingt dich h~~alt nur~~ zum hinschauen.‍️

Edit nach Hinweis.

hustbaer

@DirkB sagte in Frage zu increment:

Ein Error zwingt dich halt nur zum hinschauen.‍️

Nein, ein Error zwingt dich dazu was zu ändern. Du kannst nen Error nicht einfach suppressen. Ne Warning dagegen schon - selbst wenn mit -Werror kompiliert wird.

DirkB

@hustbaer Danke