Почему сам i++ + 1 не является неопределенным? Что гарантирует, что побочный эффект постфикса возникнет после вычисления +?

Что гарантирует, что побочный эффект постфикса возникнет после вычисления +?

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

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

Нет, вычисление значения оператора сложения использует результат вычисления значения его операндов. Операндами + являются i++ (не i) и 1. Как вы указали в вопросе, чтение i упорядочивается-до вычисления значения i++ и, следовательно, (транзитивность) упорядочено до вычисления значения +.

Следующие вещи гарантированно произойдут в следующем порядке:

1. Читать i.
2. Вычисление значения ++ (операнд: результат шага-1)
3. Вычисление значения + (операнды результат шага 2 и 1)

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

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

(Мы не знаем, правильно ли определено i++ + 1, потому что что-то может пойти не так по разным причинам: i неинициализировано или иным образом неопределенно или недействительно, или произошло числовое переполнение или переполнение указателя.)

Неопределенное поведение возникает, если на одной и той же фазе оценки мы пытаемся изменить один и тот же объект дважды: i++ + i++. Это можно запутать с помощью указателей, потому что (*p)++ + (*q)++ увеличивает один и тот же объект только в том случае, если p и q указывают на одно и то же место; в противном случае это нормально.

Неопределенное поведение также возникает, если на той же фазе оценки мы пытаемся наблюдать значение объекта, который изменяется в другом месте выражения, например i++ + i. Правая сторона + обращается к i, но это не упорядочено в отношении побочного эффекта i++ слева; оператор + не навязывает точку последовательности. Излишне говорить, что в i++ + 1 1 не пытается получить доступ к i.

Вот что происходит, когда вычисляется i++ + 1:

• Вычисляется подвыражение i++. Это дает предыдущее значение i.
• Вычисление i++ также имеет побочный эффект увеличения сохраненного значения i, но обратите внимание, что это увеличенное значение не используется.
• Вычисление подвыражения 1 дает очевидное значение.
• Оператор + вычисляется, что дает результат i++ плюс результат 1. Это может произойти только после определения значений левого и правого подвыражений (но это может постоянно происходить до или после возникновения побочного эффекта).

Побочный эффект оператора ++ гарантированно возникает только за некоторое время до следующей точки последовательности. (Это в терминах C99. Стандарт C11 представляет те же правила по-другому.) Но поскольку ничто другое в выражении не зависит от этого побочного эффекта, не имеет значения, когда он возникает. Нет конфликта, поэтому нет неопределенного поведения.

В i++ + i оценка i на RHS будет давать разные результаты в зависимости от того, произошел ли уже побочный эффект или нет. А поскольку порядок не определен, стандарт разводит руками и говорит, что поведение не определено. Но в i++ + i такой проблемы не возникает.

«Что гарантирует, что побочный эффект постфикса возникнет после вычисления +?»

Ничто не дает такой конкретной гарантии. Вы должны действовать так, как будто вы используете исходное значение i, и в какой-то момент он должен выполнить побочный эффект, но пока все ведет себя правильно, не имеет значения, как компилятор это реализует или в каком порядке . Он может (и для некоторых сценариев будет) реализовать его как примерно эквивалентный:

auto tmp = i;
i = tmp + 1; // Could be done here, or after the next expression, doesn't matter since i isn't read again 
tmp + 1;  // produces actual value of i++ + 1

or

auto tmp = i + 1;
i = tmp; // Could be done here, or after the next expression, doesn't matter since tmp isn't changed again
(tmp - 1) + 1; // produces actual value of i++ + 1

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

++i; // Usually the same as i++ + 1 if compiler has enough knowledge

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

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

Различные искажения здесь могут показаться бессмысленными (очевидно, что ++i лучше всего, если вы можете качать его, а i + 1;, за которым следует ++i, проще всего в противном случае), но они часто необходимы для работы с аппаратными атомами на данной архитектуре; если архитектура предлагает инструкцию fetch_then_add, вы бы хотели реализовать ее как:

 auto tmp = fetch_then_add(i, 1); // Returns original value of i, while atomically adding 1
 tmp + 1;

но если он предлагает только инструкцию add_then_fetch, вам нужно:

auto tmp = add_then_fetch(i, 1); // Returns incremented value of i
(tmp - 1) + 1;

Как и во многих других случаях, стандарт C++ не устанавливает предпочтительный порядок, потому что реальное оборудование не всегда взаимодействует; если он выполняет свою работу и ведет себя так, как задокументировано, на самом деле не имеет значения, какой порядок он использовал.