Я читал о порядке нарушений оценки , и они приводят пример, который озадачивает меня.

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

// snip
f(i = -1, i = -1); // undefined behavior

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

Арифметические типы (3.9.1), типы перечисления, типы указателей, указатели на типы элементов (3.9.2), std :: nullptr_t и cv-квалифицированные версии этих типов (3.9.3) вместе называются скалярными типами.

Я не вижу, как это утверждение неоднозначно в этом случае. Мне кажется, что независимо от того, оценивается ли первый или второй аргумент первым, он iзаканчивается как -1, и оба аргумента также -1.

Может кто-нибудь уточнить, пожалуйста?

ОБНОВИТЬ

Я действительно ценю все обсуждения. До сих пор мне очень нравится ответ @ damaic, так как он раскрывает подводные камни и тонкости определения этого утверждения, несмотря на то, насколько прямолинейно оно выглядит на первый взгляд. @ acheong87 указывает на некоторые проблемы, которые возникают при использовании ссылок, но я думаю, что это ортогонально аспекту побочных эффектов этого вопроса.

РЕЗЮМЕ

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

по какой причине

Основной ответ здесь приходит от Пола Дрейпера , с Мартином Дж, который внес аналогичный, но не столь обширный ответ. Ответ Пола Дрейпера сводится к

Это неопределенное поведение, потому что не определено, что это за поведение.

Ответ в целом очень хороший с точки зрения объяснения того, что говорит стандарт C ++. Также рассматриваются некоторые связанные случаи UB, такие как f(++i, ++i);и f(i=1, i=-1);. В первом из связанных случаев не ясно, должен ли первый аргумент быть, i+1а второй i+2или наоборот; во-вторых, не ясно, iдолжно ли быть 1 или -1 после вызова функции. Оба эти случая являются UB, потому что они подпадают под следующее правило:

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

Следовательно, f(i=-1, i=-1)это также UB, поскольку он подпадает под то же правило, несмотря на то, что намерение программиста является (IMHO) очевидным и однозначным.

Пол Дрэйпер также ясно указывает в своем заключении, что

Могло ли это быть определено поведение? Да. Это было определено? Нет.

что приводит нас к вопросу «по какой причине / цели было f(i=-1, i=-1)оставлено неопределенное поведение?»

по какой причине / цели

Хотя в стандарте C ++ есть некоторые упущения (возможно, небрежные), многие упущения хорошо обоснованы и служат определенной цели. Хотя я знаю, что цель часто заключается в том, чтобы «облегчить работу автора-компилятора» или «ускорить код», мне было интересно узнать, есть ли веская причина оставить f(i=-1, i=-1) UB.

вредный и суперкат дают основные ответы, которые дают повод для UB. Harmic отмечает, что оптимизирующий компилятор, который может разбить якобы атомарные операции присваивания на несколько машинных инструкций, и что он может дополнительно чередовать эти инструкции для оптимальной скорости. Это может привести к некоторым очень удивительным результатам: iв его сценарии он заканчивается как -2! Таким образом, вредный код демонстрирует, как назначение одного и того же значения переменной более одного раза может иметь негативные последствия, если операции не выполняются.

Суперкат представляет собой связное изложение подводных камней, пытающихся добиться того, f(i=-1, i=-1)на что он похож. Он указывает, что на некоторых архитектурах существуют жесткие ограничения на одновременную запись в один и тот же адрес памяти. Компилятору может быть трудно поймать это, если мы имеем дело с чем-то менее тривиальным, чем f(i=-1, i=-1).

Дэвидф также приводит пример инструкций чередования, очень похожих на вредные.

Хотя каждый из примеров вредителей, суперкатов и дэвидфов несколько надуман, вместе взятые они все же служат обоснованной причиной, почему f(i=-1, i=-1)должно быть неопределенное поведение.

Я принял ответ вредителя, потому что он наилучшим образом справился со всеми смыслами того, почему, хотя в ответе Пола Дрейпера был лучше проработан раздел «по какой причине».

другие ответы

ДжонБ указывает, что если мы рассмотрим перегруженные операторы присваивания (а не просто простые скаляры), то у нас тоже могут возникнуть проблемы.

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

Если A не секвенируется до B, а B не секвенируется до A, то существуют две возможности:

• оценки A и B не являются последовательными: они могут выполняться в любом порядке и могут перекрываться (в пределах одного потока выполнения компилятор может чередовать инструкции CPU, которые содержат A и B)

• оценки A и B имеют неопределенную последовательность: они могут выполняться в любом порядке, но не могут пересекаться: либо A будет завершен до B, либо B будет завершен до A. Порядок может быть противоположным в следующий раз, когда то же выражение оценивается.

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

Например, представьте, что было бы более эффективно обнулить память, затем уменьшить ее по сравнению с загрузкой значения -1 в. Тогда это:

f(i=-1, i=-1)

может стать:

clear i
clear i
decr i
decr i

Теперь мне -2.

Это, вероятно, фиктивный пример, но это возможно.

Во-первых, «скалярный объект» означает тип, такой как int, floatили указатель (см. Что такое скалярный объект в C ++? ).

Во-вторых, может показаться более очевидным, что

f(++i, ++i);

будет иметь неопределенное поведение. Но

f(i = -1, i = -1);

менее очевидно.

Немного другой пример:

int i;
f(i = 1, i = -1);
std::cout << i << "\n";

Какое назначение произошло «последним» i = 1, или i = -1? Это не определено в стандарте. В самом деле, это iможет быть 5(см. Ответ вредника для вполне правдоподобного объяснения того, как это может иметь место). Или ваша программа может segfault. Или переформатируйте свой жесткий диск.

Но теперь вы спрашиваете: «Как насчет моего примера? Я использовал одно и то же значение ( -1) для обоих назначений. Что может быть неясным в этом?»

Вы правы ... за исключением того, как комитет по стандартам C ++ описал это.

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

Они могли бы сделать специальное исключение для вашего особого случая, но они этого не сделали. (А почему они? Что толку было бы, что когда - нибудь , возможно , есть?) Так что , iвсе еще может быть 5. Или ваш жесткий диск может быть пустым. Таким образом, ответ на ваш вопрос:

Это неопределенное поведение, потому что не определено, что это за поведение.

(Это заслуживает особого внимания, потому что многие программисты думают, что «неопределенный» означает «случайный» или «непредсказуемый». Это не так; это означает, что не определено стандартом. Поведение может быть на 100% непротиворечивым и все же быть неопределенным.)

Могло ли это быть определено поведение? Да. Это было определено? Нет. Следовательно, это "неопределено".

Тем не менее, «undefined» не означает, что компилятор отформатирует ваш жесткий диск ... это означает, что он может и все равно будет совместимым со стандартами компилятором. На самом деле, я уверен, что g ++, Clang и MSVC будут делать то, что вы ожидали. Они просто не "должны".

Другой вопрос может быть: Почему комитет по стандартам C ++ решил сделать этот побочный эффект неубедительным? , Этот ответ будет включать в себя историю и мнения комитета. Или что хорошего в том, что этот побочный эффект не секвенируется в C ++? , которая допускает любое обоснование, было ли это фактическим обоснованием комитета по стандартам. Вы можете задать эти вопросы здесь или на сайте programmers.stackexchange.com.

Практическая причина не делать исключения из правил только потому, что два значения одинаковы:

// config.h
#define VALUEA  1

// defaults.h
#define VALUEB  1

// prog.cpp
f(i = VALUEA, i = VALUEB);

Рассмотрим случай, когда это было разрешено.

Теперь, спустя несколько месяцев, возникает необходимость изменить

 #define VALUEB 2

Кажется безобидным, не так ли? И все же внезапно prog.cpp больше не будет компилироваться. Тем не менее, мы считаем, что компиляция не должна зависеть от значения литерала.

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

РЕДАКТИРОВАТЬ

@HeartWare указал, что константные выражения формы A DIV Bне допускаются в некоторых языках, когда Bэто 0, и приводят к сбою компиляции. Следовательно, изменение константы может привести к ошибкам компиляции в другом месте. Что, ИМХО, неудачно. Но, конечно, хорошо ограничивать такие вещи неизбежным.

Путаница заключается в том, что сохранение постоянного значения в локальной переменной - это не одна атомарная инструкция в каждой архитектуре, для которой предназначен C. В этом случае процессор, на котором работает код, имеет большее значение, чем компилятор. Например, в ARM, где каждая инструкция не может нести полную 32-битную константу, хранение int в переменной требует более одной инструкции. Пример с этим псевдокодом, где вы можете хранить только 8 битов за раз и должны работать в 32-битном регистре, я - int32:

reg = 0xFF; // first instruction
reg |= 0xFF00; // second
reg |= 0xFF0000; // third
reg |= 0xFF000000; // fourth
i = reg; // last

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

reg = 0xFF;
reg |= 0xFF00;
reg |= 0xFF0000;
reg = 0xFF;
reg |= 0xFF000000;
i = reg; // writes 0xFF0000FF == -16776961
reg |= 0xFF00;
reg |= 0xFF0000;
reg |= 0xFF000000;
i = reg; // writes 0xFFFFFFFF == -1

Однако в моих тестах gcc достаточно любезен, чтобы признать, что одно и то же значение используется дважды и генерирует его один раз, и ничего странного не делает. Я получаю -1, -1 Но мой пример все еще действителен, так как важно учитывать, что даже константа может быть не такой очевидной, как кажется.

Поведение обычно указывается как неопределенное, если есть какая-то возможная причина, по которой компилятор, который пытался быть «полезным», мог сделать что-то, что вызвало бы совершенно неожиданное поведение.

В случае, когда переменная записывается несколько раз, и ничто не гарантирует, что запись происходит в разное время, некоторые виды оборудования могут позволить одновременно выполнять несколько операций «хранения» по разным адресам с использованием двухпортовой памяти. Однако в некоторых двухпортовых запоминающих устройствах явно запрещен сценарий, когда два хранилища обращаются к одному и тому же адресу одновременно, независимо от того, соответствуют ли записанные значения, Если компилятор для такой машины замечает две непоследовательные попытки записать одну и ту же переменную, он может либо отказаться от компиляции, либо гарантировать, что две записи не могут быть запланированы одновременно. Но если один или оба доступа осуществляются через указатель или ссылку, компилятор не всегда может определить, могут ли обе записи достичь одного и того же места хранения. В этом случае он может запланировать запись одновременно, вызывая аппаратную ловушку при попытке доступа.

Конечно, тот факт, что кто-то может реализовать компилятор C на такой платформе, не предполагает, что такое поведение не должно определяться на аппаратных платформах при использовании хранилищ типов, достаточно маленьких, чтобы обрабатываться атомарно. Попытка сохранить два разных значения в неупорядоченной форме может привести к странностям, если компилятор не знает об этом; например, учитывая:

uint8_t v;  // Global

void hey(uint8_t *p)
{
  moo(v=5, (*p)=6);
  zoo(v);
  zoo(v);
}

если компилятор вставляет вызов «moo» и может сказать, что он не изменяет «v», он может сохранить 5 в v, затем сохранить 6 в * p, затем передать 5 в «zoo», а затем передать содержимое v в "зоопарк". Если «zoo» не изменяет «v», не должно быть никакого способа, чтобы двум вызовам передавались разные значения, но это может легко произойти в любом случае. С другой стороны, в тех случаях, когда оба хранилища будут записывать одно и то же значение, такая странность не может возникнуть, и на большинстве платформ не будет разумной причины для того, чтобы реализация сделала что-то странное. К сожалению, некоторые авторы компиляторов не нуждаются в каких-либо оправданиях для глупого поведения, кроме «потому что это допускает Стандарт», поэтому даже эти случаи небезопасны.

Тот факт, что в этом случае результат будет одинаковым в большинстве реализаций, является случайным; порядок оценки пока не определен. Подумайте f(i = -1, i = -2): здесь порядок имеет значение. Единственная причина, по которой это не имеет значения в вашем примере - это случайность того, что оба значения -1.

Учитывая, что выражение указано как выражение с неопределенным поведением, злонамеренно совместимый компилятор может отображать неподходящее изображение при оценке f(i = -1, i = -1)и прерывании выполнения - и при этом считаться полностью правильным. К счастью, никаких компиляторов, о которых я знаю, не делают.

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

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

Это не определяет последовательность между выражениями аргументов, поэтому мы заканчиваем в этом случае:

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

На практике на большинстве компиляторов приведенный вами пример будет работать нормально (в отличие от «стирания жесткого диска» и других теоретических неопределенных последствий поведения).
Это, однако, является обязанностью, поскольку зависит от конкретного поведения компилятора, даже если два назначенных значения одинаковы. Кроме того, очевидно, что если вы попытаетесь назначить разные значения, результаты будут «действительно» неопределенными:

void f(int l, int r) {
    return l < -1;
}
auto b = f(i = -1, i = -2);
if (b) {
    formatDisk();
}

C ++ 17 определяет более строгие правила оценки. В частности, это последовательность аргументов функции (хотя и в неопределенном порядке).

N5659 §4.6:15
Оценки A и B являются неопределенно упорядоченными, когда либо A упорядочивается перед B, либо B упорядочивается перед A , но не указано, какие именно. [ Примечание : неопределенно последовательные оценки не могут перекрываться, но любой из них может быть выполнен первым. - конец примечания ]

N5659 § 8.2.2:5
Инициализация параметра, включая каждое связанное с ним вычисление значения и побочный эффект, определяется неопределенным образом относительно последовательности любого другого параметра.

Это позволяет некоторые случаи, которые были бы UB раньше:

f(i = -1, i = -1); // value of i is -1
f(i = -1, i = -2); // value of i is either -1 or -2, but not specified which one

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

struct A {
    bool first;
    A () : first (false) {
    }
    const A & operator = (int i) {
        first = !first;
        return * this;
    }
};

void f (A a1, A a2) {
    // ...
}


// ...
A i;
f (i = -1, i = -1);   // the argument evaluated first has ax.first == true

Это просто ответ на вопрос «Я не уверен, что может означать« скалярный объект »помимо чего-то вроде int или float».

Я бы интерпретировал «скалярный объект» как аббревиатуру «объекта скалярного типа» или просто «переменная скалярного типа». Затем pointer, enum(константа) имеют скалярного типа.

Это статья о скалярных типах в MSDN .

На самом деле, есть причина не зависеть от того факта, что компилятор проверит, что iему присвоено одно и то же значение дважды, так что его можно заменить одним присваиванием. Что если у нас есть выражения?

void g(int a, int b, int c, int n) {
    int i;
    // hey, compiler has to prove Fermat's theorem now!
    f(i = 1, i = (ipow(a, n) + ipow(b, n) == ipow(c, n)));
}