@ASCII

Всем привет. Никак не могу побороть Order of evaluation. В статье на cppreference, приводятся примеры UB и уже на первом я застреваю и не понимаю почему именно так:

If a side effect on a scalar object is unsequenced relative to another side effect on the same scalar object, the behavior is undefined.
Если побочный эффект для скалярного объекта не упорядочен по отношению к другому побочному эффекту для этого же объекта - поведение не определено

Собственно тут я не знаю как мыслить. Как подобного рода UB находить в программах? Я пытался применять правила, которые описаны в Secuenced before rule, но ими я не смог объяснить UB приведенного выше примера.

Собственно для примера выше пытался применить правила:

2) The value computations (but not the side-effects) of the operands to any operator are sequenced before the value computation of the result of the operator (but not its side-effects).
-------------------------------------------------------------------------------------------
Вычисление значений (но не побочных эффектов) операндов любого оператора расположены перед вычислением значения оператора в целом (но не его побочного эффекта)

8) The side effect (modification of the left argument) of the built-in assignment operator and of all built-in compound assignment operators is sequenced after the value computation (but not the side effects) of both left and right arguments, and is sequenced before the value computation of the assignment expression (that is, before returning the reference to the modified object)
-------------------------------------------------------------------------------------------
Побочный эффект (изменение левого аргумента) встроенного оператора присваивания и всех встроенных составных операторов присваивания расположены после вычисления значения (но не побочного эффекта) обоих аргументов (левого и правого) и расположены перед вычислением значения оператора присваивания (т.е. перед возвращением ссылки на измененный объект)


Но не нашел противоречий. Помогите понять это. Возможно на примере других выражений.

0

Croessmah

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

Добавлено через 1 минуту
Да, это нормальное выражение.
Да, потому что не ясно становится что в каком порядке будет вычислено.
поэтому еще раз:
В i = i++ + 1, вы i меняете дважды, причем порядок изменений не определен.

0

@ASCII

secuence point rule вроде бы в С++11 уже нету? Его заменили на sequence before rule...
В следствии чего:

До С++11 было UB
http://en.cppreference.com/w/c... eval_order

0

Croessmah

Милицию в полицию тоже переименовали
Думаю, смысл высказывания ясен

1

@ct0r

ASCII, забей на компилятор. У него вообще большая свобода действий (в разумных пределах конечно). В стандарте речь не о нем:

1

Croessmah

и на всё остальное тоже?

0

@ASCII

Вот тут мы в плотную подошли к моменту, который меня на самом деле до сих пор путает.
Смотрите, имеем общее правило для вычисления операндов какого-либо оператора:

2) The value computations (but not the side-effects) of the operands to any operator are sequenced before the value computation of the result of the operator (but not its side-effects).

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

8) The side effect (modification of the left argument) of the built-in assignment operator and of all built-in compound assignment operators is sequenced after the value computation (but not the side effects) of both left and right arguments, and is sequenced before the value computation of the assignment expression (that is, before returning the reference to the modified object)

Тут уже говорится несколько иначе. Первым делом вычисляются значения операндов оператора присваивания, то есть объект, которому присваивается и "результирующий объект", полученный после вычисления выражения, которое присваивается.

Затем, только после вычисления значений этих операндов, происходит side effect левого аргумента.
И УЖЕ ПОСЛЕ ЭТОГО, происходит финальный value computation.

То есть тут получается все упорядочено оказывается? И это сбивает с толку. Ведь если следовать этим правилам (а другие правила тут не работают вроде-бы), то по моим умозаключениям получаем такую картину:

1 Этап - вычисляем операнды.
Поехали:

Первый вариант - сначала i, потом i++ + 1
i == 0 - вычислили, i - просто идентификатор, стоящий слева, не содержит никаких подвыражений.
i++ + 1 - опять, можем считать сначала i++, потом 1, или наоборот, но в данном случае, это не важно.
i++ == 0, i становится равной 1
получаем - 1 + 1.

Второй вариант - сначала i++ + 1, потом i
получим в итоге для i++ + 1 - 1 + 1
но на стадии вычисления i получим 1, но какая разница? Если это затирается?
Ничего не поменяется ведь...
Где-то тут чувствую я ошибаюсь

ОПЕРАНДЫ ВЫЧИСЛИЛИ.


2 Этап - side effect для левого операнда
Тут ясно все, все по порядку, вычислили операнды, и начинаем изменять объект i, присваиваем результат 1 + 1

Ну и финал - возврат ссылки на i, как результата выражения.

Вот и получается, что тут будет 2

Добавлено через 2 минуты
Смысл то ясен
На самом деле я хотел сказать о другом, что некоторые операции, которые в соответствии с правилом sequence point были UB, могут не являться таковыми в соответствии с правилом sequence before

0

Croessmah

Одна поправочка.
Для вычисления значений i++ + 1 достаточно копии i.
Фактически, именно она и будет операндом,
а когда будет вычислено остальное - уже пофигу,
значение i++ + 1 от этого не изменится.

1

@ASCII

ct0r, ну не компилятор, так абстрактная машина, которая должна обеспечить наблюдаемый результат в соответствии с некими правилами. И вот как раз, почему эта машина делает именно так, а не иначе, я и хочу понять)

0

@ct0r

Croessmah, как вариант. Зачем нужно писать всякие ++ в выражениях, если это можно просто написать отдельно, что читабельнее и менее подвержено ошибкам? Разве что чужой быдлокод читать?

0

@ASCII

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

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

0

Croessmah

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

P.S. форум - отдельная эпопея, без строгих правил

0

@ASCII

Это конечно логично, но это с практической точки зрения. Я лишь преследую "понимание"
Дело в том, что читая Энтони Вильямса (я несколько книг читаю по многопоточности параллельно, кстати одну из которых мне советовали Вы и Убежденный), он начал объяснять про memory_order, то бишь про порядок доступа к памяти. А объясняя это, он вводит понятие "синхронизируется-с", которое базируется на правиле "расположено-перед", и вот из-за непонимания его, я не могу продолжить чтение

Добавлено через 1 минуту
Croessmah, а Вы чего не онлайн? Точно как бот

0

Croessmah

Ну, ежели я бот, то мне можно

1

@ASCII

Я просто вспомнил одну тему, в которой Вас ботом назвали

0

Croessmah

И сделал это ct0r.
Совпадение? Не думаю.

0

@ct0r

Вдруг знаешь сокровенный смысл

На русском конкретно эту тему жесть читать, я сам, когда первый раз читал, не понял вообще ничего Пришлось брать англ вариант и поднимать дополнительные статьи. Вот например пара:
http://preshing.com/20130702/t... -relation/
http://preshing.com/20130823/t... -relation/

1