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

а какому результату оно должно приводить? Все правильно. 2 раза проинкрементировал. 7 + 7 = 14.

Думаю с точки зрения раскрутки и очередности операций все правильно:
1-е действие:
инкремент i. Результат помещается в i (6)
2-е действие:
инкремент i. Результат помещается в i (7)
3-е действие
Берется значение i (7) И прибавляется к значению i(7) - результат 14.

А вот с точки зрения здравого смысла - судить не берусь.

Это UB. Результат может быть любым

А что такое UB?

Результат не может быть любым.
Он может быть либо 12 либо 13 либо 14

С точки зрения здравого смысло (имхо) ожидается 13

 Неопределенное поведение. Зависит от реализации.

http://en.wikipedia.org/wiki/Undefined_behavior

даже три варианта уже есть. но с там же успехом может быть и значение, например 666

Это сообщение отредактировал(а) Daevaorn - 10.5.2007, 15:27

Это стопудовый  UB. Даже у Страуструпа четко прописано.

Разве может быть абсолютно любое?

Я считал, что только в рамках последовательности операций. И у Страуструпа по-моему именно так и описывается: последовательность зависит от реализации.

Но меньше 11 результат быть не может, так же как и больше 14.

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

если это UB, то может быть всё что угодно. Любые варианты - это гадание на кофейной гуще.

Налетели!

Согласен я, естественно, просто из врожденной вредности: не любое, а из перечня (псевдо) неправильных результатов - вот я и занудствую.   

Проехали. 

Вывод: Так делать нельзя. (Таракан без ног не слышит!)

Stroustrup C++ Style and Technique FAQ
Даже пример тот же  

Фу, зардражают такие вопросики, неужели такая белиберда важна при реализации настоящей программы???

Ну почему белиберда? Не будешь знать об этом, обязательно где-нибудь что-то подобное напишешь (для "оптимизации" например, или чтоб код короче был), и будет такая программа потом работать только по полнолуниям  

Да ну его, я таким бредом заниматся не буду  
И все же вернемся к вопросу. Я тут покумекал, и выходит, так
++i; // i==6
++i;// i==7
i+i// i==13... 
но с компилятором не поспоришь... это наверное как необьяснимое чудо

Как это у тебя 7+7=13 получается - не понимаю  

Ну решил компилятор делать сложение после второго инкремента - такая у него логика.

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

не гони! Читай внимательно!!!  Там 6+7 

Добавлено через 1 минуту и 8 секунд
Так это все зависит от компилятора??? 

Добавлено через 1 минуту и 50 секунд
UB - Universal Baran?

ага  
Undefined Behavior

Это сообщение отредактировал(а) nickless - 10.5.2007, 19:55

Объяснение не сложное.
Выражение ++i + ++i. Нарушает правило которое гласит, что нельзя модифицировать переменную зажатую между 2-мя точками следования более 1-го раза. Это ведет к UB.
Здесь я так понимаю 1-я точка находится перед выражением, 2-я после.
Если сильно приперло, то можно переписать это выражение с использованием функции.



Такой вариант всегда вернет ожидаемое.
Т.к каждая ф-я обрамлена точками следования.
Хотя порядок вычисления слагаемых все-равно не определен.

Раз все пришли к такомы выводу, то будет правильным сказать тем, кто дает такие вопросы на тестах на приеме на работу (не будем говорить кто ), что этот вопрос неправилен, потому как результат зависит от компилятора и UB(хотя что это такое я так и не понял).

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

В общем, такого надо избегать.

А мне кажется, что состояние UB надо на уровне компиляции присваивать ошибку!

а компилятор не факт, что сможет сам распознать UB. Хотя кто его знает...

А можно ткнуть меня носом в компилеры, которые тут выдают че-то другое, кроме 14? Самому лень искать

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

 
это как?

Запускаешь свою программу, она начинает форматировать твой жесткий диск

it_medved, "проверка на вшивость"? Эта тема уже поднималась, implementation-defined

 perl выдал 13

C# тоже, как известно, выдает 13. Я имел в виду сиплюсовые компиляторы ;)

quote=nickless, 10.5.2007,  21:37, post1129056]$ g++ -Wall -o bla bla.cpp
bla.cpp: In function ‘int main()’:
bla.cpp:18: warning: operation on ‘i’ may be undefined
bla.cpp:18: warning: operation on ‘i’ may be undefined[/quote]

Просто замечательно! Я сам не пробовал, но варнинг - это уже хорошо.
По крайней мере, есть предупреждение.

nerezus, у меня перл выдал 14. Perl 5.8.8 Linux 

Проверил на других языках
PHP, Javascript, (и как сказали C#) - 13

Господа, я не претендую на хорошее знание сей, но ткните меня носом в UB.
UB у нас будет в случае использования постфиксного инкремента, когда переменная для последующих операций берется по значению.
В случае же префиксного инкремента результат операции инкремента всегда будет возвращен по ссылке. Приоритет инкремента всегда выше сложения (не путайте с унарной операцией +). Следовательно результат данного выражения в C/C++ гарантирован.

Пожалуйста, поправьте, мне самому стало интересно 

Ignat, по-моему именно эту ссылочку уже приводили, но всё же:

http://www.research.att.com/~bs/bs_faq2.html#undefined - из хоум пйдж Бьярни Строуструпа.

Добавлено через 4 минуты и 55 секунд

и еще дополнение к вышесказанному:
ISO/IEC 14882 C++
5. Expressions. Clause 4

перевод на русский: между последовательными точками исполнения скалярный объект может меняться не более одного раза в результате вычисления выражения. ... Иначе результат не определен (UB).

Это можно как-то гарантировать?   Имеется ввиду не только для int, но и возможную кривую реализацию перегруженного оператора класса. Да и для int, похоже, что одни компиляторы использую ссылку (результат 14), другие - копию (результат 13).


Это сообщение отредактировал(а) Hurricane - 11.5.2007, 19:29

Может быть они в С++ всё так и задумали.

Идём слева направо встречаем ++i, меняем содержимое на +1 , далее встречаем +, смотрим , что далее ++i у него больше приоритет, выполняем его, далее встречаем +, но за ним ++i - выполняем. А потом уже выполняем сложение, но в качестве аргументов не значение числовое, а значание которое находится по адресу в памяти у переменной i. Т.е. при выполнении операций он запоминает не числовое значение, а указатель на область памяти, а потом выполняет с этими указателями операции более низкого приоритета. 

Это то, как мне видется такое поведение компилятора. Впринципе, нечего необычного в поведении нету. Это чисто мои догадки, как на самом деле реализовано, я естественно не знаю.

На асме бы всё это надо написать.... мож понятнее будет. 

Я не понимаю, ну зачем зря гадать что получится, написано UB, значит UB.
Конечно в каждом компиляторе это как-то реализовано, и в польшинстве случаев он выдаст один и тот же результат, но это абсолютно не гарантирует, что результат не будет другим со включеной оптимизацией, после изменения кода в другом файле проекта, с новой версией компилятора или после внезапного лунного затмения. Нравится плясать с бубном?

я пошел еще дальше, и установил следующие факты:


Мне кажется, что компилятор интерпретирует выражение "+ ++i"  как "прибавить 12"
Завтра попробую продолжить эксперименты.

PS Шутка 
PPS Наврал, в последнем не 48 получается, придется искать другое объяснение...

Это сообщение отредактировал(а) zkv - 11.5.2007, 19:56

Да ну. Ты уверен?

На вскидку - после компайла MinGW и запуска, получаем 22 

Андефинед бехаувер и всё! Хватит собственные варианты придумывать! Есть стандарт, который чётко определяет, что мы должны и когда получить. И он определяет, что в данной ситуации мы можем получить, что угодно.

Всё!

  

Ай лайк йор джёрмен аксент!   

Любитель, 


В 6 Билдере прям в конструктор формы затолкай и откомпили, посмотришь, что получится - 24. 
__

Ну вообще да это какое-то шаманство ...  i=++i + ++i + ++i + ++i + ++i; полтос выдаёт   

Млин, уже обсудили. В билдере - 24, в MinGW - 22. Где-нибудь 23. Теоритечески может получится, скажем 115. Это будет формально удовлетворять стандарту, ибо по стандарту неизвестно, что должно получиться.

  

А как правильно произносить? А то интересно стало 

А так - ракладки лень переключать 

//это уже на BrainFuck смахивает )))))
Я знал, что без скобочек такое писать нельзя, но думал, что можно так
(++i) + (++i);

  

  

Ну, по последним указаниям ЦК ВЦСПС что-то вроде Андифайнд Бихейвьёр.   Хотя жители Соединенного Королевства могут и с этим не согласиться.

Насколько мне позволяет мой английский - "андефайнед бихавиэр"

  Раз уж на то пошло  :
undefined
behavior

Наверное, у всех временное помешательство, то ли звезды так расположены, то ли... На нескольких форумах в одно и то же время обсуждают одну и ту же тему... Бррр... Вы  проточки следования что-нибудь слышали?

тут про них уже говорили

[offtop]

На behavior у меня почему-то звук не открывается  (туоп запрос идёт - ответа нет)...

Мои преогромнейшие извинения за тягчайшее нарушение правил инглиш спикинг  
[/offtop]

  




Молодец!   А теперь всю фразу вместе повторить сможешь?   



Любитель, ну это же шутка была...   

Все, обещаю больше не хулиганить с оффтопами.

Занимательно. Но это теория. А то, что обсуждаемое выражение приводит к UB, и так уже выяснили.

эээ... а я типа серьёзно говорю что ли  Так - делать нечего...