Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > C/C++: Для новичков > С++ неверно высчитывает значение функции

Автор: Ground 19.2.2009, 17:13

Вообщем проблемка у меня следующего характера. Есть код: Код int a=5, x=2; a = ( a-- | x<<2 ) & (a<<2); printf("%d\n", a); Если я считаю вручную это выражение, то получается (0100 | 1000) & (10100) = 01100 & 10100 = 100 = 4. Если проверяю все это выражение в C++ получается 3. Если по частям, то левая часть равна 12, правая 20, 12 & 20 = 4. В чем тут загвоздка?

Автор: Sartorius 19.2.2009, 17:22

a-- уменьшит a на 1 но значение этого выражения - a до изменения. Т.е 5. Да и в правой части логического умножения a уже изменено

Автор: Lazin 19.2.2009, 17:32

это undefined behavior

Автор: Kurganec 19.2.2009, 18:48

мне кажется дело в постфиксе "--" попробуй так: Код --a;

Автор: vinter 19.2.2009, 18:59

Kurganec, Lazin дал вполне однозначный ответ

Автор: cutwater 19.2.2009, 19:38

Извините за глупый вопрос. Почему именно undefined behaviour?

Автор: Dem_max 19.2.2009, 19:57

лучше так Код a = ( (a--) | (x<<2) ) & (a<<2);

Автор: mes 19.2.2009, 20:02

Цитата(cutwater @  19.2.2009,  18:38 ) Извините за глупый вопрос. Почему именно undefined behaviour?  попробуйте (мысленно) понаблюдать  за поведением этого примера Код a= --a1 + a2; //1 a= а2 +  --a2; //2 при таком вступление Код int a =5; int a1=a; int a2=a; и таком : Код int a =5; int& a1=a; int& a2=a; во втором случае этот код альтернативен следующему Код a= --a + a; //1 a= а +  --a; //2 результат которого зависит от факторов трансляции выражения и по стандарту не определен.

Автор: mes 19.2.2009, 20:19

Цитата(Dem_max @  19.2.2009,  18:57 ) лучше так     a = ( (a--) | (x<<2) ) & (a<<2);   неа..проблема с UB не из за скобок.. если судить потому, чего хотел получить в результате тс: Цитата(Ground @  19.2.2009,  16:13 ) Если я считаю вручную это выражение, то получается (0100 | 1000) & (10100) = 01100 & 10100 = 100 = 4. то лучше  так : Код a = ((a-1) | x<<2) & a<<2;

Автор: cutwater 19.2.2009, 20:31

mes, благодарю за разъяснение.

Автор: vinter 19.2.2009, 20:39

Цитата(cutwater @  19.2.2009,  20:38 ) Извините за глупый вопрос. Почему именно undefined behaviour? дополню меса: тут два изменения одной переменной в одной точке следования, по стандарту это UB.

Автор: mes 19.2.2009, 21:33

Цитата(vinter @  19.2.2009,  19:39 ) тут два изменения одной переменной в одной точке следования что то изменение я нашел только одно...

Автор: vinter 19.2.2009, 21:45

Цитата(mes @  19.2.2009,  22:33 ) что то изменение я нашел только одно...  1. a = expression 2. a-- Добавлено через 3 минуты и 51 секунду Цитата(mes @  19.2.2009,  21:02 ) факторов трансляции выражения и по стандарту не определен. это кстати не верно, последовательность вычислений тут вообще не причем, тут все проблемы с sequence points

Автор: mes 19.2.2009, 22:05

Цитата(vinter @  19.2.2009,  20:45 ) 1. a = expression 2. a-- т.е Код  int b= --a + a;  уже не UB ?    Цитата(vinter @  19.2.2009,  20:45 ) это кстати не верно, последовательность вычислений тут вообще не причем, тут все проблемы с sequence points  a кто говорил о причинности в последовательности вычислений ? зависимость от последовательности приводилось лишь для более легкого понимания данной проблемы. да проблема с sequence points , но достаточно одного изменения и двойного использования этого значения в одной точке следования

Автор: vinter 19.2.2009, 22:10

Цитата(mes @  19.2.2009,  23:05 ) уже не UB ?   не UB Цитата(mes @  19.2.2009,  23:05 )  но достаточно одного изменения и двойного использования этого значения в одной точке следования   нет

Автор: mes 19.2.2009, 22:34

Цитата(vinter @  19.2.2009,  21:10 ) нет  vinter, давайте для начала проведем эксперемент.. у Вас VS ? что дает  нижеприведенный код ? Код int a2=5; int a1=5; int b= --a1 + a1; int c= a2 + --a2; std::cout << b<< " "<< c<< std::endl;

Автор: vinter 20.2.2009, 06:17

Цитата(mes @  19.2.2009,  23:34 ) у Вас VS ? ага Цитата(mes @  19.2.2009,  23:34 ) что дает  нижеприведенный код ? то, что и должен 8 8 mes, нет тут UB.

Автор: Ground 20.2.2009, 10:11

Всем спасибо за помощь!

Автор: mes 20.2.2009, 12:25

Цитата(vinter @  20.2.2009,  05:17 ) то, что и должен 8 8 т.е каждое слагаемое расценивалось как 4 ?  не будем сейчас задаваться вопросом о правильности результата, просто немного усложним пример : Код int b= --a1 + a1*2;  int c= a2*2 + --a2; // gcc : 12 14  Код int b= --a1 + a1/2; int c= a1/2 + --a2; //gcc: 6 6 что теперь получается и как это объяснить ?

Автор: zim22 20.2.2009, 12:52

Цитата(mes @  20.2.2009,  12:25 ) что теперь получается и как это объяснить ? можно сделать вывод, что в первую очередь вычисляются подвыражения, содержащие префиксную форму декремента. хотя я думал, что порядок вычисления подвыражений не определён...

Автор: vinter 20.2.2009, 13:16

Цитата(mes @  20.2.2009,  13:25 )  как это объяснить ? приоритетом операций   Добавлено через 53 секунды Цитата(zim22 @  20.2.2009,  13:52 ) что порядок вычисления подвыражений не определён... четко определен приоритетами.

Автор: mes 20.2.2009, 13:24

Цитата(vinter @  20.2.2009,  12:16 ) приоритетом операций   т.е у "* " и "/" разные приорететы по отношению к  "--" ?

Автор: zim22 20.2.2009, 13:28

У меня в книжечке написано, что : "За исключением логических операторов AND и OR, порядок вычисления парных операторов остается неопределенным, что обеспечивает компилятору свободу оптимизации кода." Код // Упс! Язык не определяет порядок обработки if (ia[index++] < ia[index])

Автор: mes 20.2.2009, 13:37

Цитата(zim22 @  20.2.2009,  12:28 ) if (ia[index++] < ia[index]) о! хороший пример   как раз по нашей теме, о кол-ве изменений в точке следования  демонстрация гораздо нагляднее )

Автор: vinter 20.2.2009, 17:43

Цитата(mes @  20.2.2009,  14:24 ) т.е у "* " и "/" разные приорететы по отношению к  "--" ? mes, вот чесное слово устал ты уже, открой таблицу приоритетов.. префиксный -- приоритетней всех арифметических операций. Мне больше тут нечего сказать. Цитата(mes @  20.2.2009,  14:37 ) о! хороший пример   как раз по нашей теме, о кол-ве изменений в точке следования  это unspecified behavior, чувствуешь разницу с undefined?

Автор: mes 20.2.2009, 17:48

..

Автор: vinter 20.2.2009, 17:52

mes, значит в  gcc баг, VS выдает все как должно быть Добавлено через 1 минуту и 5 секунд а попробуй так Код int b= (--a1) + (a1*2);  int c= a2*2 + (--a2); это абсолютный эквивалент твоей записи

Автор: mes 20.2.2009, 18:23

Цитата(vinter @  20.2.2009,  16:43 ) mes, вот чесное слово устал ты уже, открой таблицу приоритетов.. префиксный -- приоритетней всех арифметических операций. Мне больше тут нечего сказать. ну вот последний пример  : Код // gcc : {  int a=1, b=1; cout << a + (b - b) + ++a << endl; // 4 }{ int a=1, b=1; cout << a + b - b + ++a << endl; // 3 } интересно как в данном примере сказывается приоритет опeраций на разном результате ? Добавлено через 3 минуты и 24 секунды Цитата(vinter @  20.2.2009,  16:52 ) а попробуй так результат как и прежде Добавлено через 11 минут и 56 секунд Цитата(vinter @  20.2.2009,  16:43 ) то unspecified behavior, чувствуешь разницу с undefined?  smile  не очень..

Автор: vinter 20.2.2009, 18:55

Цитата(mes @  20.2.2009,  19:23 ) интересно как в данном примере сказывается приоритет опeраций на разном результате ? mes, как мне кажется gcc бажит, VC в обоих 4 выдает. Цитата(mes @  20.2.2009,  19:23 ) результат как и прежде Цитата(vinter @  20.2.2009,  18:52 ) значит в  gcc баг Цитата(mes @  20.2.2009,  19:23 ) не очень..  я не понимаю как ссылку выложить на rsdn :(, короче сделаем относительный путь: rsdn\C++\deepC++ там найдешь, там статей не много.

Автор: nickless 20.2.2009, 21:39

Цитата(vinter @  20.2.2009,  16:52 ) int b= (--a1) + (a1*2);  ИМХО это - UB, а1 читается 2 раза и изменяется 1 раз между точками следования, результат зависит от того, когда запишется изменение. А gcc с -Wall кстати ворнинг выдаёт: Код bla.cpp:19: warning: operation on ‘a1’ may be undefined

Автор: vinter 20.2.2009, 21:55

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

Автор: mes 20.2.2009, 22:04

Цитата(vinter @  20.2.2009,  20:55 ) т.е мы имеем два слагаемых, вычисление которых более приоритетно чем само сложение ага, только  какое из слагаемых подсчитается первым (декремент или умножение) мы не знаем...

Автор: nickless 20.2.2009, 22:19

Цитата(vinter @  20.2.2009,  20:55 ) тут одна точка Точка то одна, но даже если взять часть выражения: Код (--a1) + (a1*2) тут между двумя точками мы 2 раза читаем и декрементируем а1. Я думаю тут вот что действует: Цитата [Note: operators can be regrouped according to the usual mathematical rules only where the operators really are associative or commutative.9) For example, in the following fragment       int a, b;       /*...*/       a = a + 32760 + b + 5; the expression statement behaves exactly the same as       a = (((a + 32760) + b) + 5); due to the associativity and precedence of these operators. Thus, the result of the sum (a + 32760) is next added to b, and that result is then added to 5 which results in the value assigned to a. On a machine in which overflows produce an exception and in which the range of values representable by an int is [–32768,+32767], the implementation cannot rewrite this expression as       a = ((a + b) + 32765); since if the values for a and b were, respectively, –32754 and –15, the sum a + b would produce an exception while the original expression would not; nor can the expression be rewritten either as       a = ((a + 32765) + b); or       a = (a + (b + 32765)); since the values for a and b might have been, respectively, 4 and –8 or –17 and 12. However on a machine in which overflows do not produce an exception and in which the results of overflows are reversible, the above expression statement can be rewritten by the implementation in any of the above ways because the same result will occur. ] Тут переполнение не ожидается, так что компилятор может и соптимизировать, кроме того: Цитата Except where noted, the order of evaluation of operands of individual operators and subexpressions of indi- vidual expressions, and the order in which side effects take place, is unspecified.53) Between the previous and next sequence point a scalar object shall have its stored value modified at most once by the evaluation of an expression. Furthermore, the prior value shall be accessed only to determine the value to be stored. The requirements of this paragraph shall be met for each allowable ordering of the subexpressions of a full expression; otherwise the behavior is undefined. Т.е. раз менять местами можно, а результат будет разный - получается UB. Кстати, на VS результат всегда тот же не зависимо от оптимизации итд.? Как насчет большего числа операндов? edit Чуть подлиньше пример Код         int a1 = 5;         int a2 = 5;         int a3 = 5;         int a4 = 5;         int b = --a1 + a1*2 + a1*2 + a1*2;         int c = a2*2 + --a2 + a2*2 + a2*2;         int d = a3*2 + a3*2 + --a3 + a3*2;         int e = a4*2 + a4*2 + a4*2 + --a4;         cout << b << " " << c << " " << d << " " << e << endl;         // gcc: 28 34 34 34

Автор: vinter 20.2.2009, 22:26

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

Автор: zim22 20.2.2009, 22:26

Цитата(nickless @  20.2.2009,  22:19 )   // gcc: 28 34 34 34 VS 2008: 28 28 28 28

Автор: vinter 20.2.2009, 22:42

nickless, ты не сказал ничего нового, точнее ты не совсем верно трактовал стандарт. Цитата(nickless @  20.2.2009,  23:19 ) the implementation in any of the above ways because thesame result will occur у нас не same result Цитата(nickless @  20.2.2009,  23:19 ) The requirements of this paragraph shall be met for each allowable ordering of the subexpressions of a fullexpression; otherwise the behavior is undefined. вот оно, к чему относится Otherwise Цитата(nickless @  20.2.2009,  23:19 ) Between the previousand next sequence point a scalar object shall have its stored value modified at most once by the evaluationof an expression. Furthermore, the prior value shall be accessed only to determine the value to be stored. Добавлено через 2 минуты и 4 секунды 28 всюду, MSVC 9.0 full optimization

Автор: mes 20.2.2009, 22:50

Цитата(vinter @  20.2.2009,  21:26 ) а я знаю, они будут вычислены в пордяке приоритетов их операций! ну для начала воспользуемся одной из Ваших же ссылок(но заглянем на несколько страниц вперед) : http://www.cyberguru.ru/programming/cpp/cpp-language-straustrup2-page41.html Цитата Если нет ограничений на порядок вычисления подвыражений, то транслятор получает возможность создавать более оптимальный код. Транслятору следовало бы предупреждать о двусмысленных выражениях, но к сожалению большинство из них не делает этого.

Автор: vinter 20.2.2009, 22:55

mes, ты вообще читаешь что пишут?  ХВАТИТ ПРИВОДИТЬ ПРИМЕРЫ ВЫРАЖЕНИЙ ГДЕ ПРИОРИТЕТ ОДИНАКОВ!!!(звиняюсь) В выражениях в этом топике приоритет не одинаков!!! Добавлено через 5 минут и 42 секунды давайте немного отвлечемся и представим, что мы в 3-ем класе, нам дают задание сказать результат выражения: 7*8 + 7*8. Сколько будет? как тут можно трактовать двояко? Добавлено через 10 минут и 3 секунды icc: все 28

Автор: nickless 20.2.2009, 23:15

Цитата(vinter @  20.2.2009,  21:26 ) они будут вычислены в пордяке приоритетов их операций! В таком случае такой код был бы вполне легитимен: Код i++ + ++i если бы это выполнялось в порядке приоритетов операций, было бы: преинкремент -> плюс -> постинкремент. Однако это известный вариант UB. Так как исключений из правил тут быть не должно, думаю что "i + ++i" тоже должен быть UB (хотя причина немного другая, i изменяется только один раз). Цитата(vinter @  20.2.2009,  21:26 ) Если есть, что возразить, то приводите факты большие чем вывод gcc. Точно такого примера пока не нашел, но есть такое выражение: Код i*(++i) взято отсюда: http://gcc.gnu.org/bugs.html#nonbugs_c Добавлено через 1 минуту и 4 секунды ЗЫ Последний пример - UB Добавлено через 3 минуты и 29 секунд Кстати баг это или нет, но такой код компиляторозависим и лучше так не делать

Автор: vinter 20.2.2009, 23:22

Цитата(nickless @  21.2.2009,  00:15 ) взято отсюда: http://gcc.gnu.org/bugs.html#nonbugs_c Цитата The following expressions have unpredictable results: ... i*(++i)                 /* special case with foo=="operator*" */ .... полная чушь, GCC идет лесом, у скобок приоритет выше чем у множения, а значит они выпеолняются первымси. Тут абсолютно предсказуемый результат. GCC - 1. Цитата(nickless @  21.2.2009,  00:15 ) В таком случае такой код был бы вполне легитимен: нет, тут срабатывает правила о sequence point. 2 изменеyния в пределах одной точки -  UB Цитата(nickless @  21.2.2009,  00:15 ) "i + ++i" тоже должен быть UB нет, сначала выполняется ++, потом + ### ошибок, лучше пойду  спать

Автор: nickless 21.2.2009, 01:02

Цитата(vinter @  20.2.2009,  22:22 ) полная чушь, GCC идет лесом, у скобок приоритет выше чем у множения, а значит они выпеолняются первымси. Зря ты так категорично, gcc тоже не дураки писали   Поискал еще немного, похоже дело в этом: Цитата(nickless @  20.2.2009,  21:19 ) Between the previous and next sequence point a scalar object shall have its stored value modified at most once by the evaluation of an expression. Furthermore, the prior value shall be accessed only to determine the value to be stored. понять сложновато, но ИМХО это означает "доступ к предыдущему значению допустим лишь для вычисления значения, которое будет сохранено" Т.е. никакого чтения после того как значение было сохранено, даже теоретическая возможность этого есть UB. Сцылки: http://open-std.org/jtc1/sc22/wg14/www/docs/n1188.pdf Речь идёт о sequence points и "alowable orderings", вот этих: Цитата(nickless @  20.2.2009,  21:19 ) the order of evaluation of operands of individual operators and subexpressions of indi- vidual expressions, and the order in which side effects take place, is unspecified даётся пример что одна лишь возможность перестановки subexpressions таким образом, что переменная может быть изменена до чтения - это уже UB http://open-std.org/jtc1/sc22/wg14/www/docs/n1008.htm искать слово "prior" Предложение более внятного объяснения вышеприведённой цитаты стандарта, как пример UB даётся: Код    Note that the following expressions, with apparently similar    intent, all involve undefined behaviour:        z = x + (x = 8, 0);        z = x++ + x;        z = x++ + (x = 8, 0); http://www.embedded.com/story/OEG20020625S0041 искать "prior" Объяснение этого самого "shall be accessed only to determine the value to be stored" Короче если ты всё еще считаешь что это не UB, давай ссылку на обсуждение стандарта или хотя-бы похожий пример для VS откуда-нибудь с MSDN. ЗЫ ИМХО стоит отделить обсуждение стандарта в общие вопросы

Автор: vinter 21.2.2009, 08:52

http://msdn.microsoft.com/en-us/library/d45c7a5d(VS.71).aspx http://msdn.microsoft.com/en-us/library/yck2zaey(VS.71).aspx Короче я нигде не нашел, почуму же  Цитата(vinter @  21.2.2009,  00:22 ) i*(++i)   дает UB, кроме gcc'шной багзиллы. Какие то туманные намеки на стандарт, ничего конкретного. Цитата(nickless @  21.2.2009,  02:02 ) доступ к предыдущему значению допустим лишь для вычисления значения, которое будет сохранено ну и? а у нас не так? для чего еще оно используется? Цитата(nickless @  21.2.2009,  02:02 )  z = x++ + x; это не undefined, а unspecified. А у нас в примере был префиксный оператор, о чем я в каждом посту напоминаю, а вы это просто игнорите... Цитата(nickless @  21.2.2009,  02:02 ) Т.е. никакого чтения после того как значение было сохранено, даже теоретическая возможность этого есть UB а я это понимаю как "нельзя второй раз изменять" Подведу итог: В стандарте НЕТ четкого указания по порядку вычисления одинаковоприоритеных подвыражений, поэтому различные компиляторы творят, что хотят. Но зато есть приоритеты операций, которые, например gcc, игнорит. Что можно видеть на приммере: Цитата(vinter @  21.2.2009,  00:22 ) i*(++i) Этот пример полностью укладывается в порядок выполнения. Снчала вычисляется выражение в скобках, пооисходит сохранение нового значения i и только потом умножение.

Автор: mes 21.2.2009, 11:41

Цитата(vinter @  21.2.2009,  07:52 ) i*(++i) Этот пример полностью укладывается в порядок выполнения. Снчала вычисляется выражение в скобках, пооисходит сохранение нового значения i и только потом умножение. С порядком выполнения зависимых инструкций никто не спорит. Но вот чтение с памяти переменной i может быть произведено еще до выполнения операции инкремента. если подойти с другой стороны и раскрыть выражение то получится : Код operator*(i, operator ++(i)); а порядок вычисления аргументов функции также неопределен.

Автор: vinter 21.2.2009, 12:13

Цитата(mes @  21.2.2009,  12:41 ) если подойти с другой стороны и раскрыть выражение то получится : Код operator*(unspecified_i_for_gcc, i_incremented_yet); вот что будет

Автор: mes 21.2.2009, 12:58

Цитата(vinter @  21.2.2009,  11:13 ) вот что будет  как бы то не было, gcc не нарушает стандарта, а вот писать код руководствуясь псевдоправильным поведением студии опасно.

Автор: vinter 21.2.2009, 13:08

Цитата(mes @  21.2.2009,  13:58 ) как бы то не было, gcc не нарушает стандарта спорный вопрс я четкого регламента так и не нашел. Так, что видимо стандарт сам темнит в этой ситуации.

Автор: nickless 21.2.2009, 17:19

Хм, в MSDN тоже никакой конкретики, только на счет side effects есть: http://msdn.microsoft.com/es-es/library/8a425116.aspx Цитата Since unary increment and decrement operations involve assignments, such operations can cause side effects, as shown in the following example: x[i] = i++; В примере постинкремент, но преинкремент тоже имеет side effect, так что он ИМХО ничем не лучше. Цитата(vinter @  21.2.2009,  07:52 ) это не undefined, а unspecified Почему unspecified когда там четко написано undefined?  Цитата(vinter @  21.2.2009,  07:52 ) А у нас в примере был префиксный оператор, о чем я в каждом посту напоминаю, а вы это просто игнорите... А чем он отличается от постфиксного? Ведь по стандарту разница лишь в возвращаемом значении ++i vs. i++, а момент, когда результат инкремента будет записан в переменную определён лишь точками следования, которая в примере Код y = ++x + x; одна в конце выражения. Цитата(vinter @  21.2.2009,  07:52 ) "нельзя второй раз изменять" Про второй раз изменять там написано отдельно: Цитата(nickless @  21.2.2009,  00:02 ) Between the previous and next sequence point a scalar object shall have its stored value modified at most once by the evaluation of an expression. это условие выполняется, а вот это: Цитата(nickless @  21.2.2009,  00:02 ) Furthermore, the prior value shall be accessed only to determine the value to be stored. нет. Ты pdf читал? Там как раз про это. Цитата(vinter @  21.2.2009,  07:52 ) В стандарте НЕТ четкого указания по порядку вычисления одинаковоприоритеных подвыражений, поэтому различные компиляторы творят, что хотят. Но зато есть приоритеты операций, которые, например gcc, игнорит Приоритеты операций в данном случае не имеют значения, как и в a[i] = i++; Цитата(vinter @  21.2.2009,  07:52 ) Этот пример полностью укладывается в порядок выполнения. Порядок выполнения тут не нарушается, проблема в том, что выражение ++i имеет побочный эффект. По стандарту, результат побочного эффекта достигнет переменной к следующей точке следования, а не до оператора умножения. Получается два возможных варианта: [точка следования n] читаем i, инкрементируем, сохраняем новое значение, читаем i, складываем, [точка следования n+1] [точка следования n] читаем i, инкрементируем, читаем i, складываем, сохраняем новое значение, [точка следования n+1] Оба варианта следуют стандарту, а результат разный - слöедовательно это UB. Цитата(vinter @  21.2.2009,  07:52 ) Снчала вычисляется выражение в скобках, пооисходит сохранение нового значения i и только потом умножение Нет, порядок выполнения не влияет на сохранение нового значения. Если бы это было что-то вроде Код ++i && a = i то да, новое значение i было бы сохранено до присваивания, т.к. && определяет точку следования, а + или * точки следования не определяют. Цитата(mes @  21.2.2009,  10:41 ) С порядком выполнения зависимых инструкций никто не спорит. Но вот чтение с памяти переменной i может быть произведено еще до выполнения операции инкремента. +1 Цитата(mes @  21.2.2009,  10:41 ) если подойти с другой стороны и раскрыть выражение то получится : ... а порядок вычисления аргументов функции также неопределен. Это пример только для C++, в случае с C причина немного другая.

Автор: vinter 21.2.2009, 18:36

Цитата(nickless @  21.2.2009,  18:19 ) Хм, в MSDN тоже никакой конкретики, только на счет side effects есть: там есть гарантия порядка выполнения, например что при < вычислен сначала будет левый аргумент. Цитата(nickless @  21.2.2009,  18:19 ) А чем он отличается от постфиксного? у префиксного наивысший приоритет, у постфиксного наинизший. Цитата(nickless @  21.2.2009,  18:19 ) Furthermore, the prior value shall be accessed only to determine the value to be stored. блин, а по твоему когда мы пишем просто x* мы как то вступаем в противоречие с этой фразой? Цитата(nickless @  21.2.2009,  18:19 ) По стандарту, результат побочного эффекта достигнет переменной к следующей точке следования, а не до оператора умножения. как это? т.е ты хочешь сказать, что изменения в переменных происходят только по завершении точки следования? Это 100% чушь, т.к в этом случае ни одно выражение не может быть построено. Пример с твоих слов: x = y * ++z; UB, т.к z изменится ятолько по завершению эволюции выражения.

Автор: mes 21.2.2009, 18:57

Цитата(vinter @  21.2.2009,  17:36 ) x = y * ++z; UB, т.к z изменится ятолько по завершению эволюции выражения. да z в памяти изменится только по завершению эволюции, но это не UB так как никто не использует эту память. а то что предназначено для умножения как правый множитель (но это не z!)  будет иметь значение инкрементированого z. P.S. мне кажется Вы упустили, что арифметические операции проходят не с ячейками памяти, а с регистрами в которые вначале загружаются значения и из которых в дальнейшем результат записывается в память. т.е значения которое отдала переменная для расчетов и которое в действительности хранится в ее памяти в определенные моменты времени отличаются..

Автор: nickless 21.2.2009, 18:57

Цитата(vinter @  21.2.2009,  17:36 ) блин, а по твоему когда мы пишем просто x* мы как то вступаем в противоречие с этой фразой? Нет конечно Цитата(vinter @  21.2.2009,  17:36 ) т.е ты хочешь сказать, что изменения в переменных происходят только по завершении точки следования? Это 100% чушь Нравится тебе это или нет, но в стандарте так и написано: Цитата Evaluation of an expression may produce side effects. At certain specified points in the execution sequence called sequence points, all side effects of previous evaluations shall be complete and no side effects of subsequent evaluations shall have taken place. The grouping of operators and operands is indicated by the syntax.72) Except as specified later (for the function-call (), &&, ||, ?:, and comma operators), the order of evaluation of subexpressions and the order in which side effects take place are both unspecified. Цитата(vinter @  21.2.2009,  17:36 ) Пример с твоих слов: x = y * ++z; UB, т.к z изменится ятолько по завершению эволюции выражения. Да, z изменится только после завершения эвалюации, но это не UB, т.к. z больше не используется, а результат выражения ++z чётко определён. Добавлено через 1 минуту и 32 секунды Цитата(nickless @  21.2.2009,  17:57 ) эвалюации    ЗЫ Медленно я пишу...

Автор: vinter 21.2.2009, 19:04

Цитата(nickless @  21.2.2009,  19:57 ) Нравится тебе это или нет, но в стандарте так и написано ок. Стандарт все таки более дебилен, чем я думал. Спасибо за дискуссию.

Автор: Ground 23.2.2009, 08:46

Две ссылки приведенные выше дают разную информацию: http://www.do2.rksi.ru/library/courses/demo/tema1_3.dbk http://www.cyberguru.ru/programming/cpp/cpp-language-straustrup2-page39.html Первая говорит, что у постфиксного инкремента и декремента самый низний приоритет из операций, а префиксного самый высокий. Вторая ссылка утверждает что у них одинаковый приоритет. Кому верить? И в какой все-таки последовательности нужно считать a=(a--|x<<2)&(a<<2), чтобы получить 3, как и выдает си? Получается выполнять сначало все действия в скобках, за исключением декремента, и потом от финального значения отнимать единицу?

Автор: vinter 23.2.2009, 09:37

Цитата(Ground @  23.2.2009,  09:46 ) a=(a--|x<<2)&(a<<2) тут стопроцентный Undefined behavior Цитата(Ground @  23.2.2009,  09:46 ) Первая говорит, что у постфиксного инкремента и декремента самый низний приоритет из операций, а префиксного самый высокий. Вторая ссылка утверждает что у них одинаковый приоритет. Кому верить? лучше все таки верить Страуструпу. Но там не совсем верная таблица приведена. Сейчас открыл книгу приоритет постфиксных операций, выше чем префиксных..

Автор: Ground 23.2.2009, 10:15

Я просто пытаюсь понять алгоритм си. Все дело в том, что в дальнейших вычислениях у меня есть квадратный корень, и при ответе a=4 (если считать выражение UB, и исправить это), у меня получается отрицательное значение под ним, а при a=3 (исходное выражение, без исправлений) все сходится. Т.е. программа считает как мне необходимо дальше по заданию. Возможно это ошибка в задании. Если читать первую ссылку, то получается что у постфиксного декремента самый низкий приоритет, и тогда мы вычисляем (a|x<<2)&(a<<2), а потом находим декремент этого выражения, то у меня получится 3, как и у программы. В резуальтате выходит, что дело в приоритете операций.

Автор: vinter 23.2.2009, 10:37

Ground, не читай первую ссылку  Я сам ее счиатл верной, сейчас открыл Страуструпа и понял, что та ссылка не верна. Попробуй найди Страуструп 3-е издание, там наиболее верная таблица.

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)