(y++)-(--y)
-
Tim schrieb:
C-Realsatire
und wo ist der witz?
-
Tim schrieb:
Du brauchst da keine plausible Erklärung für zu suchen, da das ganz klassisches undefined behaviour ist. Du darfst y nicht zweimal innerhalb eines sogenannten sequence points ändern.
s/innerhalb eines/zwischen zwei/
aber ansonsten ack.
-
SG1 schrieb:
Tim schrieb:
Du brauchst da keine plausible Erklärung für zu suchen, da das ganz klassisches undefined behaviour ist. Du darfst y nicht zweimal innerhalb eines sogenannten sequence points ändern.
s/innerhalb eines/zwischen zwei/
aber ansonsten ack.
*g* ich habs mir nach dem abschicken nochmal durchgelesen und wusste dass das jemand bemängelt
Nene, schon o.k.
@fricky: Ich bemängele damit die übertriebene Mehrfachbelegung eines Schlüsselworts.
-
Tim schrieb:
@fricky: Ich bemängele damit die übertriebene Mehrfachbelegung eines Schlüsselworts.
stimmt, sowas ist doof. erst recht weil 'static' vorher schon doppelt belegt war.
-
Ich hoffe ich störe eure nette Runde nicht allzusehr mit meiner Frage :D, aber Tim:
"Du brauchst da keine plausible Erklärung für zu suchen, da das ganz klassisches undefined behaviour ist. Du darfst y nicht zweimal innerhalb eines sogenannten sequence points ändern."
Könntest du mir das bitte in etwas weniger fachmännischen Worten erklären, ich sitz da etwas auf der Leitung
-
^^er mein damit, dass ein compiler sich's ausuchen kann, in welcher reihenfolge er das hoch- und runterzählen in deinem code macht. schau mal hier: http://en.wikipedia.org/wiki/Sequence_point
-
Alles klar, jetzt ist mir das ganze schon etwas näher gerückt, wäre das eigentlich auch ein undefined behavior:
x= (y == ++x);
Oder stellt hier == einen sequence Point dar welcher mir das ++x vor der Auswertung des Ausdrucks (y == ++x) ohne Probleme um 1 erhöht?
Danke sehr
-
blacklights schrieb:
Alles klar, jetzt ist mir das ganze schon etwas näher gerückt, wäre das eigentlich auch ein undefined behavior:
x= (y == ++x);ja, auch. mach doch sowas:
if (y == x+1) x = 1; else x = 0;
^^ das ist über jeden zweifel erhaben und man sieht sofort was passieren soll.
-
Zur Vollständigkeit:
The following are the sequence points described in 5.1.2.3:
— The call to a function, after the arguments have been evaluated (6.5.2.2).
— The end of the first operand of the following operators: logical AND && (6.5.13); logical OR || (6.5.14); conditional ? (6.5.15); comma , (6.5.17).
— The end of a full declarator: declarators (6.7.5);
— The end of a full expression: an initializer (6.7.8); the expression in an expression statement (6.8.3); the controlling expression of a selection statement (if or switch) (6.8.4); the controlling expression of a while or do statement (6.8.5); each of the expressions of a for statement (6.8.5.3); the expression in a return statement (6.8.6.4).
— Immediately before a library function returns (7.1.4).
— After the actions associated with each formatted input/output function conversion specifier (7.19.6, 7.24.2).
— Immediately before and immediately after each call to a comparison function, and also between any call to a comparison function and any movement of the objects passed as arguments to that call (7.20.5).
-
blacklights schrieb:
Alles klar, jetzt ist mir das ganze schon etwas näher gerückt, wäre das eigentlich auch ein undefined behavior:
x= (y == ++x);
da hat jemand die verlinkte Wiki Seite nicht gelesen
-
supertux schrieb:
blacklights schrieb:
Alles klar, jetzt ist mir das ganze schon etwas näher gerückt, wäre das eigentlich auch ein undefined behavior:
x= (y == ++x);
da hat jemand die verlinkte Wiki Seite nicht gelesen
Doch eigentlich schon, deshalb habe ich auch nochmal eine Frage gestellt um zu sehen ob ichs auch kapiert habe.
An der Stelle wäre auch meine Frage angebracht, auf wiki steht:
Between evaluation of the left and right operands of the && (logical AND), || (logical OR), and comma operators. For example, in the expression *p++ != 0 && *q++ != 0, all side effects of the sub-expression *p++ != 0 are completed before any attempt to access q.
Wobei:
, all side effects of the sub-expression *p++ != 0 are completed before any attempt to access q.
Mit "side effects" ist an dieser Stelle unteranderem das Erhöhen von *p um 1 gemeint, oder?
-
blacklights schrieb:
An der Stelle wäre auch meine Frage angebracht, auf wiki steht:
Between evaluation of the left and right operands of the && (logical AND), || (logical OR), and comma operators. For example, in the expression *p++ != 0 && *q++ != 0, all side effects of the sub-expression *p++ != 0 are completed before any attempt to access q.
Wobei:
, all side effects of the sub-expression *p++ != 0 are completed before any attempt to access q.
aber du hast weder &&, || noch 'nen 'komma-operator' drin. nur 'n vergleich.
blacklights schrieb:
Mit "side effects" ist an dieser Stelle unteranderem das Erhöhen von *p um 1 gemeint, oder?
ja. irgend ein blödmann hat den ausdruck 'seiteneffekt' dafür erfunden, obwohl er völlig unpassend klingt. aber ist nun mal so.
-
+fricky schrieb:
blacklights schrieb:
An der Stelle wäre auch meine Frage angebracht, auf wiki steht:
Between evaluation of the left and right operands of the && (logical AND), || (logical OR), and comma operators. For example, in the expression *p++ != 0 && *q++ != 0, all side effects of the sub-expression *p++ != 0 are completed before any attempt to access q.
Wobei:
, all side effects of the sub-expression *p++ != 0 are completed before any attempt to access q.
aber du hast weder &&, || noch 'nen 'komma-operator' drin. nur 'n vergleich.
blacklights schrieb:
Mit "side effects" ist an dieser Stelle unteranderem das Erhöhen von *p um 1 gemeint, oder?
ja. irgend ein blödmann hat den ausdruck 'seiteneffekt' dafür erfunden, obwohl er völlig unpassend klingt. aber ist nun mal so.
Alles klar, Dankeschön für die Hilfe
-
+fricky schrieb:
^^er mein damit, dass ein compiler sich's ausuchen kann, in welcher reihenfolge er das hoch- und runterzählen in deinem code macht.
Nein, das meint er nicht damit, das wäre "unspecified behavior".
Im C-Standard gibt es, wenn das Verhalten nicht explizit definiert ist, drei Abstufungen von Freiheiten, die man dem Compiler zugesteht:
(1) "implementation-defined" bedeutet, dass der Compilerhersteller die gewählte Variante dokumentieren muss. Das betrifft beispielsweise die Größe der Datentypen.
(2) "unspecified" bedeutet, dass der Compiler eine denkbare und sinnvolle Variante wählen kann und muss. Bei der Auswertung des Ausdruckes
f() + g()
ist es dem Compiler beispielsweise freigestellt, zuerst f oder zuerst g aufzurufen. Eine der beiden Varianten muss es sein, aber es muss nicht dokumentiert werden, es muss nichtmal immer dieselbe Reihenfolge sein.(3) "undefined" bedeutet, dass es keinerlei vorgeschriebene Einschränkungen des Verhaltens gibt. Es könnte irgendeine sinnvolle Variante sein, es könnte eine nicht sinnvolle Variante sein, es könnte auch ein Absturz, Datenverlust oder sonst irgendwas sein. Klassisches Beispiel ist das Dereferenzieren eines nicht initialisierten Zeigers. Aber auch die hier vorliegende Situation, bei der ein und dasselbe Objekt zwischen zwei Sequenzpunkten mehrfach verändert wird, hat undefiniertes Verhalten (und überhaupt sehr viel in C).
-
Bashar schrieb:
+fricky schrieb:
^^er mein damit, dass ein compiler sich's ausuchen kann, in welcher reihenfolge er das hoch- und runterzählen in deinem code macht.
Nein, das meint er nicht damit, das wäre "unspecified behavior".
ah, danke. ich bin von realen C-compilern ausgegangen, da werden solche undefinierten audrücke immer 'irgendwie' verarbeitet (meistens in der reihenfolge, in der man's nicht erwartet).
-
+fricky schrieb:
ich bin von realen C-compilern ausgegangen, da werden solche undefinierten audrücke immer 'irgendwie' verarbeitet (meistens in der reihenfolge, in der man's nicht erwartet).
Das ist ja auch zu erwarten. Aber ich nehme an, es gibt Plattformen, bei denen nicht jede mögliche Reihenfolge vernünftiges Verhalten hat. Vielleicht haben die ganz schwierige Adressierungsmodi, irgendwelche Probleme mit Pre/Postinkrement, Locking-Geschichten oder sonstwas. Müsste man mal erforschen, aber dazu fehlt mir die Energie
-
Hallo!
Zeile 9:
Hier verstehe ich nicht ganz, wieso für x=0 herauskommt, denn:
y++ => Erhöhung von y um 1 nach der Operation x= ...
--y => y wird um 1 reduziert vor der Operation x=..
Somit würde ja stehen: x=6-5=1unabhaengig vom undefined behaviour usw... wuerde ich sagen, dass
Dein Compiler ein Ergebnis liefert, welches ich erwarten wuerde.Der Code
a=y++; b=a- --y;
ergibt, das b = 0 ist.
Denn y++ gibt den y-Wert zurueck und erhoeht ihn dann um eins.
--y dekrementiert y und gibt dann den Wert zurueck.Somit wurde Dein Code von links nach rechts ausgewertet.
Gruesse,
Richie
-
Bashar schrieb:
... Müsste man mal erforschen, aber dazu fehlt mir die Energie
Aha, Stromrechnung nicht bezahlt?