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

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

Проблема стара как "С"...
Скобки используйте и все дела.

GCC 3.4.5
gcc -o x x.c
x = 14
gcc -Os -o x x.c
x = 14
gcc -O0 -o x x.c
x = 14
gcc -O1 -o x x.c
x = 14
gcc -O2 -o x x.c
x = 14
gcc -O3 -o x x.c
x = 14

Понимать он должен правильно В данном выражении префиксные инкременты имеют максимальные приоритеты, посему формально при тупом исполнении 14, но выражение глупозапутанное и как раз тот случай, когда оптимизаторы 'ломаются' . Просто так писать не надо!
И насчет слова 'оптимизация' - она очень разная бывает, у меня, например, Watcom при включении в проект со вполне любовно подобранной оптимизацией без вопросов выдал 14.
A IAR честно предупредил, что не понимает такой хрени и за результат не ручается.

не страдайте фигней.
Вот вам выдержка из стандарта С++
i = ++i + i //the behavior is unspecified

Смотрим внимательно и находим одно отличие:

Как любителю стандартов, вам надо было не искать отличия, а пойти почитать стандарт.
Там написано, что при наличии сторонних эффектов но описанных в стандарте поведение не определено. Тут как раз имеем сторонний эффект не описанный в стандарте.

Тут (x= ++i + i) в отличии от(i = i++ + i) его нет.

Побочные эффекти возникают, когда объект меняется больше одного раза между точками следования. Очевидно, что в рассматриваемом выражении x= ++i + i, объект i меняется всего один раз.

А в исходном ++i + ++i?

В исходном - не хорошо c точки зрения потенциального возникновения неоднозначности .

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

Угу







В выражении ++i + ++i значение i изменяется два раза, следовательно, по стандарту результат неопределенный.

В выражении ++i + i значение i считывается два раза, один раз для вычисления нового сохраняемого значения i слева, второй раз - при вычислении правой части сложения, следовательно, по стандарту результат неопределенный.

Обратите внимание, что ключевой момент для применения правила об одном считывании - значение переменной i модифицируется в выражении.

Удивительно, что столь очевидная вещь собрала столько сломанных копий. Есть кучу куда более прикольных особеностей в с++

Таки да! Имеет место быть неопределенность исполнения side effect от оператора ++ по отношению к операции сложения. Взгляд замылил префиксный инкремент , который на самом деле не имеет отношения к делу.
Если вернуться к первоисточнику, то в этом конкретном случае ничего принципиально не разрешимого для компилятора нет, однако смягчения правил игры установленные стандартом в виде виде sequence point позволяют ему не разбираться с этими заморочками. Совершенно правильный подход к делу, поскольку заумные выражения усложняет жизнь компилятору и на самом деле ничего не дают програмисту.
С другой стороны никто не может запретить разбирать и более сложные конструкции в этом случае он (Watcom, например) спокойно жует и такие перлы и выдает правильное значение 14. Те компиляторы, которые не разбирают - ругаются (IAR). Те компиляторы, которые не разбирают, молчат и выдают произвольное значение - бяки .


Где Вы копья увидели? А вещь не очевидная, если считать очевидным не использование такой дури в явном виде ни при каких условиях .

Это в китайских исходниках такое нашли?

Скобки не определяют Sequence points и не помогут ничем.

По всем сообществам разбирают эту строчку. И куча народа дже после правильного ответа продолжают что-то придумывать, строить какие-то предположения..
Еще и колеги на работе по аське достали этим выражением.

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

//--------------------------------------

Когда-то полдня убил на глюк ИАРА. Код ниже работал в MCС18 (пик), а в ИАРЕ (4.30, ARM) нет.

unsigned char c;
char* cr;

выше инициализация credential;

while((c = *credential) != '\r') // Advance until \r (end of credentials)
credential++;
*credential = '\0'; // NULL char to replace \r.

//---------------------------
Пока не заменил на:

do { if(*credential=='\r') break;
credential++;
}while(1);
credential++;
*credential = '\0'; // NULL char to replace \r.

Причем игрался с оптимизациями - не помогало. Вылетало за пределы массивов.

Почему 14?
IMHO правильное значение может быть 12, 13, но никак не 14.

Компилятор ничего не должен..
В стандарте не написано, что он должен посылать такое выражение.



А вот это уже 100% глюк компилятора. Точнее оптимизатора.

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





Выполняется инкремент i, как самый приоритетный (левый или правый на Ваше усмотрение )
Затем второй инкремент i, потом сложение, как самая неприоритетная операция.
Выполнены все три операции в порядке приоритетов. Все.

http://electronix.ru/forum/index.php?s=&am...st&p=249062



Это цитата из стандарта. На русский переводить не нужно? Как видите, компилятор никому ничего не должен, все остальное - фантазии.



Да, именно так. Пусть аргументы '+' вычисляются справа налево Сначала считывается значение правого i (5) прибавляем 1, записываем значение правого i. Запоминаем результат правого подвыражения (6). Затем считываем значение левого i (6), прибавляем 1, сохраняем новое значение i, запоминаем результат левого подвыражения (7). Теперь к результату правого подвыражения (6) прибавляем результат левого подвыражения (7) и в результате получаем 13.

Альтернатива - когда результаты преинкремента прописываются в переменные в конце вычисления выражения (имеют право - точка сохранения результатов однозначно не определена). В этом случае результат двух подвыражений будет 6, и их сумма будет 12.

А вот как получить 14 - не понимаю

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

Вот 'запоминаем' это и есть чистейшей воды фантазии. С какого бодуна компилятор будет заводить промежуточную переменную-дубль для запоминания? Только если у него совсем крышу снесло.

Это или инкремент суммирование инкремент суммы с тем-же результатом - имеет право, только если это он сделает без warnig я не пойму такой поступок.

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

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



По правилам формальной семантики выражений языка С (так как мы говорим о "правильности" выражений - мы на время забываем, что такое выражение в целом - undefined bihavior). '+' суммирует результаты своих левого и правого подвыражений. С какого бодуна результат первого подвыражения изменяется после его вычисления?



Я-то как раз понимаю, как компилятор получает такой результат. У многих компиляторов один из промежуточных этапов компиляции - получение трехадресного кода. При этом разработчики компиляторов, помня правило, процитированное мною первым в первом моем посте, полагаются на то, что переменная i второй раз в одном и том же выражении не изменится, и в ней можно сохранить промежуточный результат подвыражения вместо заведения еще одной промежуточной переменной. Такое предположение компилятора в данном случае является ошибочным. То есть такое поведение - побочный эффект, допускаемый стандартом как undefined bihavior, но никак не "правильное" поведение компилятора.

P.S. Что касается "небрежно написанных компиляторов" - есть такая русская пословица, про зеркало. Компилятор может выдавать что угодно в подобных выражениях. Делать или нет специальный анализ выражения для генерации предупреждений в таких случаях - это выбор разработчиков компиляторов, тем более, что во многих случаях (с указателями) компилятор просто не может знать, что два подвыражения модифицируют один объект. Поэтому лучше так не пишите, а если пишите - то ничего не требуйте от компилятора. Язык С, действительно, налагает довольно высокие требования на квалификацию программиста в части неиспользования некоторых конструкций.

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

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

Выражение k=++i + ++i; являсь совершенно диким, тем не менее поддается однозначной разборке согласно основополагающим правилам операций и их приоритетов. Про трудности компиляции такого и _правильное_ решение стандарта разрешить не заморачиваться с такой разборкой все ясно.


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

Это их право. Только у меня тоже есть право не использовать такие компиляторы .
Поскольку сегодня выходной день, то я провел маленький тест используемых мною в повседневной жизни компиляторов.
OpenWatcom, GCC, Borland не возразили и выдали правильный результат.
IAR, VisualDSP - выдали предупреждение.
Все это с учетом того, что warnigs я всегда по максимуму активизирую и без оптимизации компиляцию не пользую.
Результат меня полностью удовлетворил - по поводу разборки этой дури у меня претензий к используемым мною компиляторам нет и с их разработчиками у меня коннсенсус .


К чему это адресное обращение? Я призывал так писать???

P.S.
Пожалуй по четвертому кругу я больше не пойду изъясняться по проблемам k=++i + ++i;

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



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

Я приводил.

Приводили, но не с точки зрения базовых правил а с точки зрения как может быть построена разборка выражения в потрохах компилятора. Что позволяет объяснить, почему появляется неправильный результат и почему стандарт не требует разбирать такую ерунду. Но все это не имеет отношения к пользователю компилятора написавшего дурацкое, сложно разбираемое компилятором (если он за это возьмется!), хреново оптимизируемое и трудно понимаемое человеком, но вполне однозначо трактуемое выражение - "берем одну едиственную переменную, инкрементируем один раз, инкрементируем второй раз, прибавляем к ней ее-же значение.

Про "принципиальное значение" я ни сном ни духом не поминал. Повторяю - выдаваемый результат лично для меня имеет некоторое (а отнюдь не принципиальное) значение только в плане оценки компилятора и только в том единственном случае, когда он не выдав предупреждения выдал результат отличный от 14. В проведенных тестах я даже не смотрел на результат у компиляторов которые выдали warning-и. Во настолько он для меня имеет "принципиальное значение"
Извиняю.

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

Жаль.

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



Нет, грамматические и семантические правила - это часть стандарта языка, а не реализации конкретного компилятора. Я ссылался на грамматические правила и на семантику операций. Выражение 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.

Ну про f() это естественно правильно - по другому было-бы крайне странно. С main() выдал warning расписавшись в непонятках - тоже каой-же после этого спрос.

Зксперименировал для начала с OpenWatcom...

Аналогично. C приличными оптимизациями все сводится к

Пришлось извне передавать.

Это вариант с разнообразными оптимизаторами:

и вообще без оптимизации:

Но при любых уровнях оптимизации "неизменно превосходный результат". warnin-ов нет. Причем, что действительно интересно даже в вырожденном случае с тупым возвратом значения , где уже все заранее решено - 14.




В обоих случаях оптимизации говорит нельзя?

В любом случае, это не есть доказательство "правильности" значения 14.



gcc на x86 неизменно возвращает 14. в том числе, из f()

Ну скажем так, это некий результат полученный на нескольких компиляторах, без сопутствующего warning (типа не сомневались в результате?). Все другие компиляторы выдающие отличный результат неизменно генерили при этом warning. Как это можно истолковать?
А с учетом того, что авторы компиляторов разбираюся в этом скорее всего лучше, чем все здесь собравшиеся вместе взятые?

Я мельком глянул на f() - естественно ошибся .

Да. Для O2 и O0

Как истолковать? Как невыдачу предупреждения на undefined bihavior код.

То, что "А с учетом того, что авторы компиляторов разбираюся в этом скорее всего лучше, чем все здесь собравшиеся вместе взятые" - утверждение просто смешное. Компилятор - не такая уж непостижимая для понимания программа. Очень много народу писало разнообразные компиляторы - ну разве что не такие оптимизирующие.

Вы никогда не читали учебники по устройству компиляторов? Вот, например, из недавних был издан на русском языке в 2001 году. "Компиляторы. Принципы, технологии, инструменты". Ахо, Сети, Ульман. Авторы, кстати - классики по теории компиляции. Очень рекомендую.