Вычисления без последствий (ака последовательности)

Собственные операторные выражения не эквивалентны перегруженным операторным выражениям. Существует точка последовательности при привязке значений к аргументам функции, что делает версии operator++() корректными. Но этого не существует для случая родного типа.

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

§ 5/4:

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

Изменить для C ++ 0x (обновлено)

§1.9 / 15:

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

Обратите внимание, однако, что вычисление значения и побочный эффект – две разные вещи. Если ++i эквивалентно i = i+1 , то + – вычисление значения, а = – побочный эффект. От 1,9 / 12:

Оценка выражения (или подвыражения) в общем случае включает в себя как вычисления значений (включая определение идентичности объекта для оценки glvalue и получение значения, ранее назначенного объекту для оценки prvalue), так и инициирование побочных эффектов.

Поэтому, хотя вычисления значений более строго секвенированы в C ++ 0x, чем C ++ 03, побочных эффектов нет. Два побочных эффекта в одном и том же выражении, если не указано иначе, производят UB.

В любом случае вычисления значений упорядочиваются по их зависимостям данных, а побочные эффекты отсутствуют, их порядок оценки ненаблюдаем, поэтому я не уверен, почему C ++ 0x старается не говорить ничего, но это просто означает, что мне нужно больше читать из писем Бёма и друзей.

Редактировать # 3:

Спасибо Johannes за то, что он справился с моей лень, чтобы напечатать «упорядоченный» в моей панели поиска PDF-файлов. Я собирался спать и вставать на последних двух изменениях в любом случае … правильно; v).

§5.17 / 1, определяющие операторы присваивания

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

Кроме того, §5.3.2 / 1 о предъявлении оператора

Если x не относится к типу bool, выражение ++ x эквивалентно x + = 1 [Примечание: см. … дополнение (5.7) и операторы присваивания (5.17) …].

Таким образом, ++ ++ x является сокращением для (x +=1) +=1 . Итак, давайте интерпретировать это.

• Оцените 1 на дальней RHS и спуститесь в parens.
• Оцените внутренний 1 и значение (prvalue) и адрес (glvalue) x .
• Теперь нам нужно значение подвыражения + =.
  • Мы закончили вычисление значений для этого подвыражения.
  • Побочный эффект назначения должен быть секвентирован до того, как будет доступно значение присвоения!
• Назначьте новое значение x , которое идентично результату glvalue и prvalue для подвыражения.
• Сейчас мы вышли из леса. Теперь все выражение сводится к x +=1 .

Итак, тогда 1 и 3 хорошо определены, а 2 и 4 – неопределенное поведение, чего вы ожидаете.

Единственный сюрприз, который я обнаружил при поиске «секвенированных» в N3126, был 5.3.4 / 16, где реализации разрешено вызывать operator new перед оценкой аргументов конструктора. Это круто.

Редактировать # 4: (О, какая запутанная сеть мы переплетаемся)

Йоханнес отмечает, что в i == ++i; glvalue (aka адрес) i неоднозначно зависит от ++i . Значение glval – это значение i , но я не думаю, что 1.9 / 15 должен включать его по той простой причине, что glvalue именованного объекта является константой и на самом деле не может иметь зависимости.

Для информативного соломона подумайте

 ( i % 2? i : j ) = ++ i; // certainly undefined 

Здесь glvalue LHS of = зависит от побочного эффекта на prvalue i . Адрес i не подлежит сомнению; результат ?: есть.

Возможно, хороший контрпример

 int i = 3, &j = i; j = ++ i; 

Здесь j имеет glvalue, отличное от (но идентичного) i . Является ли это четко определенным, но i = ++i нет? Это представляет собой тривиальное преобразование, которое компилятор может применить к любому случаю.

1.9 / 15 следует сказать

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

Рассматривая выражения, подобные упомянутым, я считаю, что полезно представить машину, где память имеет блокировки, так что чтение места памяти как части последовательности чтения-модификации-записи приведет к попыткам чтения или записи, кроме заключительной записи последовательность, которая будет остановлена ​​до тех пор, пока последовательность не завершится. Такая машина вряд ли была бы абсурдной концепцией; действительно, такая конструкция может упростить многие многопоточные сценарии кода. С другой стороны, выражение типа «x = y ++;» может выйти из строя на такой машине, если «x» и «y» были ссылками на одну и ту же переменную, а сгенерированный код компилятора сделал что-то вроде read-and-lock reg1 = y; reg2 = REG1 + 1; написать x = reg1; write-and-unlock y = reg2. Это было бы очень разумной кодовой последовательностью для процессоров, где запись вновь вычисленного значения налагала бы задержку конвейера, но запись в x блокировала бы процессор, если бы у были схожими с одной и той же переменной.