int i=0; i = i++ + ++i - i++; чему равно i?

CoolCmd
Даже не знал что такой бред возможен. Но только какой в этом смысл?
Как я понимаю присваиваем x единицу, а потом этому выражению что-то другое.
Imho это что-то вроде:

Бред и только.

 

Booster
Не спорю, это бред. За такой код (и за тот что в заголовке написан) нужно яйца отрывать.
Но вопрос был другой. Хочется понять, правильно ли я понял цитату из стандарта. Т.е. первое выражение вроде дает UB, а второе - нед?

 

CoolCmd
IMHO интерпретация обоих выражений очевидна ( и + x, - 2 просто отбрасываются компиллером за ненадобностью), а потому это не должно быть UB. Хотя это наверно просто частный случай таких г:

Что уже наверняка UB. Так как х фигуриует и в левых и правых частях, с изменением по-месту. То есть x меняется и слева и с права.

 

CoolCmd

IMHO, если написать так:

Код (Text):

1. y = (x = 1) + x;
2. y = (x = 1) - 2;

то первое - UB (не определено, какой операнд сложения вычисляется первым), второе - нет - y по-любому равен -1. Значит, за вторую конструкцию яйца отрывать не надо, а за первую - вполне богоугодное дело Любопытно другое - стандарт считает UB некоторые конструкции, которые по логике вроде бы однозначны - выдирка из стандарта (правда он у меня довольно старый, надо посмотреть обновления:

Код (Text):

1. i = v[i ++]; // the behavior is undefined
2. i = 7 , i++ , i ++; // i becomes 9
3. i = ++ i + 1; // the behavior is undefined
4. i = i + 1; // the value of i is incremented

 

Ustus
И чего же тут не так? 1 и 3 UB и в африке UB.

 

Booster
Да вроде как 3 по логике прозрачно... тогда и i = ++i - это тоже UB? Конечно, возможно это оправдано для применения каких-то дико оптимизирующих компиляторов, причем не обязательно x86, но уж очень это жестоко...

 

Ustus

Да это UB. И дело тут даже не в оптимизации, (хотя здесь она далеко не дикая, а даже простая, выполнение операции без повторной работы с результатом), а в том что тут нету единственно верной интерпретации. Ну кто скажет как она должна единственно правильно интерпертироваться? По-мойму ни кто. ++i определено, а i = ++i уже нет. Компилятор не обязан разбираться в подобном изврате, у него и так проблем хватает, уж извольте говорить на понятном ему языке. Да и ++i не для подобного задумывалась.

 

Ustus

Я думаю, это сделано для упрощения определения UB.
Фактически все вышеперечисленные случаи UB сводятся к одному правилу: порядок вычисления аргументов ф-ции неопределён.
Ведь i = ++i в функциональном виде будет:
Assign(i, Increment(i))

 

Код (Text):

1. i = ++i - это тоже UB? ... уж очень это жестоко

А разве нет? )
Но в любом случае, человек в здравом уме так никогда не напишет, поэтому какая разница на практике?

 

nerezus

Для меня - никакой я так не пишу.
И вообще, что значит "какая разница"? Есть логика, а есть философия. Сабж относится ко второй. А философия это такая штука, что всегда неравнодушна к дурацким вопросам