аналогично!
почему 14 ???
13 и баста...
вариант с 12 - доспустим,но это добжен быть невероятно глупый компилятор, причем с патароченными критериями и правилами оптимизации...

но а 14 откуда берется?
и почему у gcc тоже 14???

я прошу, нет, ... требую... объясните плз...

я конечно не виликий гуру - но тут то заблудиться трудно!
13 и ничего иного...
x = ++i+ ++i

разбиваем как это делает компилятор
temp1 = ++i (стало 6)
temp2 = ++i (стало 7)
x=temp1+temp2 (стало 13)

от куда 14???

...и вообще! что это у людей за безгранично глупая привычка все писать без скобок !?
что за мода надеяться на безграничный интелект компилятора?
...истинну глаголю - индусы писали это эйфелеву конструкцию!
не иначе ...или [CENSORED]!

а глупость то видать явно в компиляторах и это напоминает подвох с x=2+2*2, чему равен x?

.

Сообщение отредактировал PrSt - May 13 2007, 16:54

Пора рассматривать известную шутку Ричи и Кернигана

for(;P('\n'),R-;P('|'))for(e=C;e-;P('_'+(*u++/8)%2))P('| '+(*u/4)%2);

Вдруг и это вызовет полемику?

1. Да простит меня великий All, что я поднял эту волну... Просто мною овладело любопытство.

2. Я про явное отличие компиляторов С/С++ и С# скажу. Точнее скажу свои доводы, как эти компиляторы понимают код
x = ++i + ++i;

Компиляторы С/С++ складывают (последняя операция -- сложение) переменную i c переменной i, в то время как C# складывае результат выражения ++i с результатом выражения ++i.

Таким образом, для С/С++ на момент сложения переменных, они будут равны 7 (даром, что это одна и та же переменная!), результат получаем -- 14. C# складывает результаты выражений: первый результат на момент сложения равен 6, второй -- 7, что в итоге дает 13.

Отсюда вопрос -- что должны складывать компиляторы: результаты выражений или значения переменных?

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

И еще, наверно стоит зайти на РСДН, посмотреть что там говорят гуру. (Сылку я приводил в первом посте.)

Сообщение отредактировал zhevak - May 14 2007, 00:13

А то, что значение переменной может поменяться в результате прерывания? Или в начале каждой sequence point прерывание запрещать, а потом разрешать?

Сообщение отредактировал vromanov - May 14 2007, 00:11

не-е, ну... предполагается, что переменная i -- это обычная переменная, не volatile. Определена внутри какой-нибудь функции, т.е. размещается либо на стеке, либо в регистрах МП. Иначе говоря, никто из вне ее торкнуть не может.

Про исходный пример все ясно. Так просто нельзя писать, т.к. результат по стандарту не определен. Мы уже про другое.

Если следовать строго правилам стандарта, отличие может возникнуть только в том случае, если переменная i объявлена как volatile. В этом случае можно сказать однозначно: так как результат ++i по стандарту не является lvalue, компилятор не имеет права считывать i второй раз и должен использовать результат вычисления выражения.

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

В пост #4 при компилляции добавляем -Wall и получаем warning и значение 14.
Напомню, это в GCC 3.4.5 x86

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

Еще раз.

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

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