nickless, тут одна точка, разберем выражение:
int b= (--a1) + (a1*2); 
т.к мы имеем два подвыражения, которые имеют одинаковый приоритет срабатывает lef-to-right-order. Следовательно первым отрабатывай декремент, затем умножение и только потом сложение. Тту не надо программирование знать это элементарная математика, т.е мы имеем два слагаемых, вычисление которых более приоритетно чем само сложение. Следовательно я не вижу даже unspecified, не то что undefined.. GCC смущает, не верю в тупость такого хорошего компилятора.. В результате есть небольшой ступор, но судя здравой логике - в gcc баг.

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

Точка то одна, но даже если взять часть выражения:

тут между двумя точками мы 2 раза читаем и декрементируем а1.

Я думаю тут вот что действует:

Тут переполнение не ожидается, так что компилятор может и соптимизировать, кроме того:


Т.е. раз менять местами можно, а результат будет разный - получается UB.

Кстати, на VS результат всегда тот же не зависимо от оптимизации итд.?
Как насчет большего числа операндов?
edit Чуть подлиньше пример


Это сообщение отредактировал(а) nickless - 20.2.2009, 22:24

а я знаю, они будут вычислены в пордяке приоритетов их операций!
Мне честно надоело уже говорить в стену, вот вам 2 ссылки: 
http://www.do2.rksi.ru/library/courses/demo/tema1_3.dbk
http://www.cyberguru.ru/programming/cpp/cp...up2-page39.html
там расписаны приоритеты операций.
Если есть, что возразить, то приводите факты большие чем вывод gcc.

VS 2008: 28 28 28 28

Это сообщение отредактировал(а) zim22 - 20.2.2009, 22:29

nickless, ты не сказал ничего нового, точнее ты не совсем верно трактовал стандарт.


у нас не same result

вот оно, к чему относится Otherwise


Добавлено через 2 минуты и 4 секунды
28 всюду, MSVC 9.0 full optimization

ну для начала воспользуемся одной из Ваших же ссылок(но заглянем на несколько страниц вперед) :

http://www.cyberguru.ru/programming/cpp/cp...up2-page41.html


  

Это сообщение отредактировал(а) mes - 20.2.2009, 22:51

mes, ты вообще читаешь что пишут?
 ХВАТИТ ПРИВОДИТЬ ПРИМЕРЫ ВЫРАЖЕНИЙ ГДЕ ПРИОРИТЕТ ОДИНАКОВ!!!(звиняюсь)
В выражениях в этом топике приоритет не одинаков!!!

Добавлено через 5 минут и 42 секунды
давайте немного отвлечемся и представим, что мы в 3-ем класе, нам дают задание сказать результат выражения: 7*8 + 7*8.
Сколько будет? как тут можно трактовать двояко?

Добавлено через 10 минут и 3 секунды
icc: все 28

В таком случае такой код был бы вполне легитимен:

если бы это выполнялось в порядке приоритетов операций, было бы: преинкремент -> плюс -> постинкремент. Однако это известный вариант UB.
Так как исключений из правил тут быть не должно, думаю что "i + ++i" тоже должен быть UB (хотя причина немного другая, i изменяется только один раз).


Точно такого примера пока не нашел, но есть такое выражение:

взято отсюда: http://gcc.gnu.org/bugs.html#nonbugs_c

Добавлено через 1 минуту и 4 секунды
ЗЫ Последний пример - UB

Добавлено через 3 минуты и 29 секунд
Кстати баг это или нет, но такой код компиляторозависим и лучше так не делать  

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


нет, тут срабатывает правила о sequence point. 2 изменеyния в пределах одной точки -  UB


нет, сначала выполняется ++, потом +
### ошибок, лучше пойду  спать 

Это сообщение отредактировал(а) vinter - 20.2.2009, 23:24

Зря ты так категорично, gcc тоже не дураки писали  

Поискал еще немного, похоже дело в этом:

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

Сцылки:

http://open-std.org/jtc1/sc22/wg14/www/docs/n1188.pdf
Речь идёт о sequence points и "alowable orderings", вот этих:

даётся пример что одна лишь возможность перестановки subexpressions таким образом, что переменная может быть изменена до чтения - это уже UB

http://open-std.org/jtc1/sc22/wg14/www/docs/n1008.htm искать слово "prior"
Предложение более внятного объяснения вышеприведённой цитаты стандарта, как пример UB даётся:


http://www.embedded.com/story/OEG20020625S0041 искать "prior"
Объяснение этого самого "shall be accessed only to determine the value to be stored"


Короче если ты всё еще считаешь что это не UB, давай ссылку на обсуждение стандарта или хотя-бы похожий пример для VS откуда-нибудь с MSDN.


ЗЫ ИМХО стоит отделить обсуждение стандарта в общие вопросы

http://msdn.microsoft.com/en-us/library/d45c7a5d(VS.71).aspx
http://msdn.microsoft.com/en-us/library/yck2zaey(VS.71).aspx

Короче я нигде не нашел, почуму же 

дает UB, кроме gcc'шной багзиллы. Какие то туманные намеки на стандарт, ничего конкретного.



ну и? а у нас не так? для чего еще оно используется?


это не undefined, а unspecified. А у нас в примере был префиксный оператор, о чем я в каждом посту напоминаю, а вы это просто игнорите...

а я это понимаю как "нельзя второй раз изменять"

Подведу итог: В стандарте НЕТ четкого указания по порядку вычисления одинаковоприоритеных подвыражений, поэтому различные компиляторы творят, что хотят. Но зато есть приоритеты операций, которые, например gcc, игнорит. Что можно видеть на приммере:

Этот пример полностью укладывается в порядок выполнения. Снчала вычисляется выражение в скобках, пооисходит сохранение нового значения i и только потом умножение.

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

а порядок вычисления аргументов функции также неопределен.


Это сообщение отредактировал(а) mes - 21.2.2009, 11:42

вот что будет

как бы то не было, gcc не нарушает стандарта, а вот писать код руководствуясь псевдоправильным поведением студии опасно.