фича компиляторв, инкремент переменной Опции

[zhevak]

На форуме программистов (здесь http://www.rsdn.ru/Forum/?mid=2481623) с пацанами сейчас подняли интересную тему. Думаю, что си-шникам тоже следует остерегаться подобного кода. В двух словах проблема состоит в том, как компилятор должен понимать оператор инкремента.

int i;
int x;

i = 5;
x = ++i + ++i;

Чему в результате будет равно х ?

Прикол в том, что MS VC++ 6.0 и VC++.NET дают результат, равный 14. Майкрософтовский C# и IAR говорят, что х = 13. А более всего удивил Watcom -- у него результат зависит от того, включена-ли оптимизация или нет...

Я, конечно, понимаю, что код, который обсуждается, несколько далек от жизни, но все же, знать о таких прибабахах -- надо.

Вечером дома, попробую еще в CodeVision эту фичу покрутить.

[singlskv]

Я Вам не помешаю ?
Выскажу свое ИМХО:
- Компилятор который не выдет warning в такой ситуации, вне зависимости от уровня оптимизации,
это компилятор который не следует стандарту С.
- соглашусь с Oldring, 12 или 13 еще как-то укладывается в то, как учитывая стандарт С,
компилятор должен был бы разбирать это выражение
- результат 14 для большинства компиляторов говорит только о том,
что "очень хотелось соптимизировать" и компилятор "успешно" справился с этой
задачей...
2zligo
Если Вы имеете в виду такую предсказуемость работы "оптимизаторов" в компиляторах,
то с Вами я тоже полностью согласен

[cebotor]

Я Вам не помешаю ?
Выскажу свое ИМХО:
- Компилятор который не выдет warning в такой ситуации, вне зависимости от уровня оптимизации,
это компилятор который не следует стандарту С.
- соглашусь с Oldring, 12 или 13 еще как-то укладывается в то, как учитывая стандарт С,
компилятор должен был бы разбирать это выражение
- результат 14 для большинства компиляторов говорит только о том,
что "очень хотелось соптимизировать" и компилятор "успешно" справился с этой
задачей...
2zligo
Если Вы имеете в виду такую предсказуемость работы "оптимизаторов" в компиляторах,
то с Вами я тоже полностью согласен

все операции детерминированы . в выражении ++i + ++i во втором "отделении спектакля"
производиться только сложение двух подвыражений - а подвыражения эти - равны текущему значению i (вариант а), либо вычисленному значению подвыражения (вариант б). нигде не написано в стандарте про то какой вариант является правильным - именно поэтому это и называется undefined behavior. неправ тот компилятор который не показал ворнинг - а число при этом можно выдавать где то от 12-ти до 14-ти

[Oldring]

все операции детерминированы . в выражении ++i + ++i во втором "отделении спектакля"
производиться только сложение двух подвыражений - а подвыражения эти - равны текущему значению i (вариант а), либо вычисленному значению подвыражения (вариант б). нигде не написано в стандарте про то какой вариант является правильным - именно поэтому это и называется undefined behavior. неправ тот компилятор который не показал ворнинг - а число при этом можно выдавать где то от 12-ти до 14-ти

Еще раз.

Результат всего выражения компилятор имеет право выдать любой - хоть -666, потому что undefined behavior.

Но интерпретация значения выражения ++i прописана в стандарте совершенно четко. Результат не является lvalue. Следовательно, это не есть значение переменной i, а именно вычисленное значение подвыражения. В корректных выражениях различие можно обнаружить только если i - volatile.