Какое значение примет элемент n[1] после выполнения команд:

Question

int i = 0, n[] = {7, 5, 3, 1};
for ( ; i<3; n[i++] = n[i]);

Дело в том, что два разных компилятора (Code Blocks и CppDroid) выдают два разных значения. В Code Blocks получается 5, а в CppDroid - 3. Так какой же ответ правильный? Проблема в одном из компиляторов, или само задание некорректно?

Answer 1

По-моему, порядок вычисления выражения слева и выражения справа при выполнении присваивания не оговорен стандартом (порядок определяется конкретным компилятором).

Для C++11, раздел 5.17:

The assignment operator (=) and the compound assignment operators all group right-to-left. All require a modifiable lvalue as their left operand and return an lvalue referring to the left operand. The result in all cases is a bit-field if the left operand is a bit-field. In all cases, the assignment is sequenced after the value computation of the right and left operands, and before the value computation of the assignment expression. With respect to an indeterminately-sequenced function call, the operation of a compound assignment is a single evaluation

Поскольку итоговый результат вычисления зависит от порядка вычисления операндов, то и возникает undefined behavior.

Для C++17, раздел 5.18, порядок вычисления уже более строго определен:

The right operand is sequenced before the left operand.

Поэтому неопределенного поведения не должно возникать. И после выполнения цикла массив не изменится, поэтому n[1] равно 5.

Answer 2

Компилятор C++ имеет право переупорядочивать инструкции в целях оптимизации.

Рассмотрим выражение

n[i++] = n[i]

Как оно может быть интерпретировано?

Первый вариант.

int tmp = i;
i = i + 1;
n[tmp] = n[i];

То есть, например, при i == 0

n[0] = n[1]

Второй вариант

auto tmp_n = n[i];
int tmp_i = i;
i = i + 1;
n[tmp_i] = tmp_n;

То есть, при i == 0

n[0] = n[0];

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

Неопределено.

P.S. Кстати, Code::Blocks это не компилятор, а среда разработки, не имеющая собственного компилятора.

Answer 3

Имеет место неопределенное поведение программы. Согласно стандарту C++ (1.9 Program execution)

15. ...If a side effect on a scalar object is unsequenced relative to either another side effect on the same scalar object or a value computation using the value of the same scalar object, and they are not potentially concurrent (1.10), the behavior is undefined.

Там же в стандарте приведен схожий пример

i = i++ + 1; // the behavior is undefined 

Answer 4

Никакой.

Фрагмент n[i++] = n[i] провоцирует неопределённое поведение, так как операция приравнивания не является точкой следования.

Это значит, что оператор волен выбирать, какое именно выражение надо вычислять первее: n[i++] или n[i]. Единственное ограничение — к моменту присваивания оба фрагмента должны дать по значению (ссылку и число соответственно).

Неопределённое поведение следует из того, что компилятор рассматривает обе части независимо. Соответственно, i++ из левой части и i из правой друг с другом как бы не связаны. Мало того, что чтение-изменение-запись постинкремента может быть переставлено местами с просто чтением, так они могут быть ещё и перемешаны друг с другом.

На большом StackOverflow уже был задан вопрос о том, почему присваивание не является точкой следования:

Имеется ли какое-нибудь обоснованию тому, что оператор = не является точкой следования как в Си, так и в C++?

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

К примеру, && должен быть точкой следования из-за short-circuiting: если левая часть оператора ложна, правая его часть вычислена не будет. Это связано не столько с оптимизацией, сколько с возможностью создания зависимости правой части от левой (к примеру, в ptr && ptr->data). Поэтому левая часть обязательно должна быть вычислена строго до правой, чтобы знать, надо ли вычислять правую часть вообще.

В случае же с = подобной причины не существует. Хотя этот оператор и является присваиванием (...), точный порядок вычисления сторон не имеет значения, пока они выполняются до собственно присваивания.

P. S. Кстати, проблема с ++i + ++i имеет такую же первопричину.

Answer 5

Неопределенное поведение. Компилятор g++, запущенный с ключем -Wall честно предупреждает об этом.

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

avp@wubu:hashcode$ cat t.c
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>


int
main (int ac, char *av[])
{
  int i = 0, n[] = {7, 5, 3, 1};
  int l = 0;
  for ( ; i<3; n[i++] = n[i]) {
    printf("loop %d i = %d\n", l++, i);
    for (int j = 0; j < 4; j++)
      printf("%d ", n[j]);
    puts("");
  }

  puts("");
  printf("result i = %d\n", i);
  for (int j = 0; j < 4; j++)
    printf("%d ", n[j]);
  puts("");
}

avp@wubu:hashcode$ g++ -Wall t.c
t.c: In function ‘int main(int, char**)’:
t.c:11:28: warning: operation on ‘i’ may be undefined [-Wsequence-point]
   for ( ; i<3; n[i++] = n[i]) {
                            ^
avp@wubu:hashcode$ ./a.out 
loop 0 i = 0
7 5 3 1 
loop 1 i = 1
5 5 3 1 
loop 2 i = 2
5 3 3 1 

result i = 3
5 3 1 1 
avp@wubu:hashcode$ 

Как видите n[1] = 3, т.е. этот компилятор в операторе присваивания (в данном случае это завершающая часть for(;;)) берет текущее значение i, вычисляет и запоминает адрес цели, увеличивает i, на основе уже нового значения i выбирает данные источника (n[i]) и копирует их по адресу цели.