Оператор Comma и приращение при печати в C [duplicate]

Хотя маловероятно, что какие-либо компиляторы и процессоры действительно это сделают, было бы законно в соответствии со стандартом C для компилятора реализовать «i ++» с последовательностью:

In a single operation, read `i` and lock it to prevent access until further notice
Compute (1+read_value)
In a single operation, unlock `i` and store the computed value

Пока Я не думаю, что какие-либо процессоры поддерживают аппаратное обеспечение, позволяющее эффективно выполнять такую ​​работу, легко представить себе ситуации, когда такое поведение упростит многопоточный код (например, это гарантирует, что если два потока попытаются выполнить описанную выше последовательность одновременно i будет увеличиваться на два), и совершенно немыслимо, чтобы какой-то будущий процессор мог предоставить что-то подобное.

Если компилятор должен был написать i++, как указано выше (в соответствии с стандарт) и должны были интерпретировать приведенные выше инструкции в ходе оценки общего выражения (также законного), и если бы не было уведомления о том, что одна из других инструкций имела доступ к i, это было бы возможно (и юридический) для компилятора для генерации последовательности instr которые могли бы затормозить. Разумеется, компилятор почти наверняка обнаружит проблему в том случае, если в обоих местах используется одна и ту же переменная i, но если подпрограмма принимает ссылки на два указателя p и q и использует (*p) и (*q) в приведенном выше выражении (вместо того, чтобы дважды использовать i), компилятору не потребовалось бы распознавать или избегать тупиковой ситуации, которая произошла бы, если бы тот же адрес объекта был передан как для p, так и для q.

Большинство ответов здесь цитируется на стандарте C, подчеркивая, что поведение этих конструкций не определено. Чтобы понять, почему поведение этих конструкций не определено, давайте сначала разобрать эти термины в свете стандарта C11:

Последовательность: (5.1.2.3)

При любых двух оценки A и B, если A секвенирован до B, то выполнение A должно предшествовать исполнению B.

Непоследовательность:

Если A не секвенируется до или после B, то A и B не имеют последовательности.

Оценки могут быть одной из двух вещей:

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

Точка последовательности:

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

Теперь, перейдя к вопросу, для выражений типа

int i = 1;
i = i++;

стандарт говорит, что:

6.5 Выражения:

< blockquote>

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

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

Давайте переименуем i слева от назначения be il и справа от присваивания (в выражении i++) будет ir, тогда выражение будет выглядеть как

il = ir++     // Note that suffix l and r are used for the sake of clarity.
              // Both il and ir represents the same object.  

Важной точкой в отношении оператора Postfix ++ является то, что:

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

Это означает, что выражение il = ir++ может быть оценено как

temp = ir;      // i = 1
ir = ir + 1;    // i = 2   side effect by ++ before assignment
il = temp;      // i = 1   result is 1  

или

temp = ir;      // i = 1
il = temp;      // i = 1   side effect by assignment before ++
ir = ir + 1;    // i = 2   result is 2  

, что приводит к двум различным результатам 1 и 2, которые зависят от последовательности побочных эффектов при назначении и ++ и, следовательно, вызывает UB.

Часто этот вопрос связан как дубликат вопросов, связанных с кодом типа

printf("%d %d\n", i, i++);

или

printf("%d %d\n", ++i, i++);

или схожими вариантами.

Пока это также неопределенное поведение , как уже было сказано, существуют тонкие различия, когда printf() участвует в сравнении с выражением, таким как:

   x = i++ + i++;

В следующем statement:

printf("%d %d\n", ++i, i++);

порядок оценки аргументов в printf() является неуказанным . Это означает, что выражения i++ и ++i могут быть оценены в любом порядке. Стандарт C11 содержит некоторые соответствующие описания:

Приложение J, неуказанное поведение

Порядок, в котором обозначение функции, аргументы и подвыражения в аргументах вычисляются в вызове функции (6.5.2.2).

3.4.4, неуказанное поведение

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

ПРИМЕР Пример неуказанного поведения - это порядок, в котором оцениваются аргументы функции.

Неисправное поведение НЕ является проблемой. Рассмотрим этот пример:

printf("%d %d\n", ++x, y++);

Это также имеет неуказанное поведение , потому что порядок оценки ++x и y++ не указан. Но это совершенно законное и достоверное утверждение. В этом утверждении есть неопределенное поведение no undefined. Поскольку модификации (++x и y++) выполняются с различными объектами.

Что делает следующий оператор

printf("%d %d\n", ++i, i++);

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

---

] Еще одна деталь заключается в том, что запятая , участвующая в вызове printf (), является разделителем , а не оператором запятой .

Это важное различие, потому что -коммутатор вводит точку последовательности между оценкой их операндов, что делает следующий законным:

int i = 5;
int j;

j = (++i, i++);  // No undefined behaviour here because the comma operator 
                 // introduces a sequence point between '++i' and 'i++'

printf("i=%d j=%d\n",i, j); // prints: i=7 j=6

Оператор запятой оценивает свои операнды слева направо и дает только значение последнего операнда. Таким образом, в j = (++i, i++); приращения ++i i до 6 и i++ дают старое значение i (6), которое назначено на j. Затем i становится 7 из-за пост-приращения.

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

printf("%d %d\n", ++i, i++);

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

---

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

Это сообщение: Неопределенное, неопределенное и определенное по реализации поведение также актуально.

Невозможно объяснить поведение, потому что оно вызывает как неопределенное поведение неопределенного поведения , так и неопределенное поведение , поэтому мы не можем делать какие-либо общие предсказания об этом коде, хотя, если вы прочитайте работу Олве Модала, такие как Deep C и Unspecified и Undefined , иногда вы можете делать хорошие догадки в очень конкретных случаях с конкретным компилятором и средой, но пожалуйста, не делайте этого где-нибудь рядом с производством.

Итак, переходим к неуказанному поведению , в черновик c99 standard раздел 6.5 пункт 3 говорит ( emphasis mine ):

Группировка операторов и операндов обозначается синтаксисом.74) За исключением случаев, указанных ниже (для функции -call (), & amp ;, ||,?: и запятые), порядок оценки подвыражений и порядок, в котором происходят побочные эффекты, не определены.

Итак, когда у нас есть такая строка:

i = i++ + ++i;

, мы не знаем будет ли сначала оцениваться i++ или ++i. Это главным образом для того, чтобы дать компилятору лучшие варианты оптимизации .

Здесь также имеется неопределенное поведение , так как программа модифицирует переменные (i ], u и т. д.) более одного раза между точками последовательности . Из проекта стандартного раздела 6.5 пункта 2 ( emphasis mine ):

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

он ссылается на следующие примеры кода как неопределенные:

i = ++i + 1;
a[i++] = i; 

Всего в этих примерах код пытается изменить объект более одного раза в одной и той же точке последовательности, что закончится с ; в каждом из этих случаев:

i = i++ + ++i;
^   ^       ^

i = (i++);
^    ^

u = u++ + ++u;
^   ^       ^

u = (u++);
^    ^

v = v++ + ++v;
^   ^       ^

Неопределенное поведение определяется в черновик c99 стандарта в разделе 3.4.4 как:

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

и неопределенное поведение определено в разделе 3.4.3 следующим образом:

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

и отмечает, что:

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