На форуме программистов (здесь 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 эту фичу покрутить.

Не вижу именно разбора выражения. По порядку, что в каком порядке должно вычисляться и почему?

Жаль.

То есть ссылку на свой пост, про который Вы утверждаете, что там описали формальный разбор выражения, Вы привести не можете?



Нет, грамматические и семантические правила - это часть стандарта языка, а не реализации конкретного компилятора. Я ссылался на грамматические правила и на семантику операций. Выражение x = ++i + ++i; должно быть грамматически разобрано следующим образом (запись дерева - стандартная префиксная)



Как при аккуратном исполнении этого дерева разбора в соответствии с семантическими правилами языка можно получить 14 - не понимаю.

P.S. Если придираться - в этом дереве уже расрыта операция ++i как эквивалентная (i+=1).

По моему все очень просто, т.к. код архитектурно зависимый.
Даже считая по дереву:

С другой стороны, результат в java(как в стековой архитектуре).

Все прозрачно)))

Так вот откуда взялась эта третья операция - x = i + i?
Как она получена из дерева разбора выражения?

P.S.

++i эквивалентно i += 1.

В дереве ясно написано x=add {++i,++i}, т.е. сначала выполняются все преинкрементом, а затем выполняется операция сложения. Т.к. операции преинкремента выполняются с одной ячейкой памяти - происходит увеличение ячейки на 2. Операция сложения складывает 2 ячейки памяти с адресом &i, т.е. как и написано в коде. Это вполне справедливо при рассмотрении x86 как машины с памятью, которой она и является)))

Я не могу спрогнозировать результат только на регистровой машине(классической или как при представлении x86 в регистровом эквиваленте), т.к. неопределенность будет зависеть от результата оптимизации. На регистровой машине будут справедливы 2 подхода : -неоптимизированный (по первичному графу) получится как в x86, т.к. сначала выполнятся все "пре" операции и получится результат как в машине с памятью;
-оптимизированный, когда все будет делаться на лету и максимальным использованием регистров код может выглядеть как

Не совсем - в дереве ясно написано, что нужно сложить результат первого подвыражения и результат второго подвыражения. Если бы результат подвыражений был lvalue - тогда при вычислении сложения нужно было бы взять у lvalue (неформально - ссылки на объект) значение объекта, и тогда можно было бы прочитать из переменной i результат, отличный от приписанного в i в подвыражении, если бы преобразование lvalue в значение выполнялось после вычисления обоих подвыражений как преобразование типа для операции '+'. Но так как результат вычисления подвыражения lvalue не является - мы не имеем права считывать его обратно из i и обязаны использовать именно то значение, которое было вычислено соответсвующим подвыражением. Одно из подвыражений всегда даст 6, в каком бы порядке ни выполнять операции.

Что происходит в реальных компиляторах - вполне понятно, это не вопрос. Речь шла про "правильность", причем, после закрывания глаз на то, что такое выражение в целом имеет undefined bihavior.

Потому и "undefined bihavior", что по моему мнению оператор + складывает 2 ячейки памяти с адресом I, а по вашему он заводит дополнительную переменную. Тут всё и кроется))

Вся эта бодяга действительно отдана на откуп компилятору в зависимости от платформы. Но что интересно - в результате реального эксперимента все компиляторы для x86 платформы выдали тот самый результат, а под ARM и BF выдали warning - не смогли на штатном механизме обеспечить?
Интересный такой нюанс. Надо будет GNU на не на x86 платформе спытать.

undefined bihavior - потому что часто зависит, например, от порядка вычисления подвыражений, да и для свободы оптимизатора полезно, когда побочные эффекты можно вычислять в произвольном порядке.

Ваше мнение о том, "что оператор + складывает 2 ячейки памяти с адресом i" противоречит утверждению из стандарта, что результат вычисления ++i не есть lvalue. Так что такую интерпретацию принять не могу как "правильную"




arm-elf-gcc версии 4.1.1 выдает 13.

Посмотрите полученный ассемблерный код на своей машине и всё станет ясно: на ARM без использования стека (ес-но) i=13, на х86 без стека i=14, со стеком i=13.
Вообще беспредметный спор о тёмных сторонах компилляторов, ИМХО.

Безусловно.
Спор был о том, можно ли считать результат 14 "правильным", называя все остальное - "неправильным".

Молча?

nios2-elf-gcc выдает без оптимизации 13, с оптимизацией - 14.
Хотя оптимизированный код выглядит совсем оптимизированным "movi R2, 14" )))
И говорит что так делать нельзя.

По умолчанию - да.

В программе, приведенной ниже, с ключем -Wsequence-point выдается предупреждение "warning: operation on 'i' may be undefined" внутри main(), но не внутри f(). В обоих случаях - 13.



P.S. С включенной оптимизацией -O3 main своится к возврату 13.