Вызывают ли скобки порядок оценки в (текущем) C?

Соответствующий раздел стандарта - C11 5.1.2.3 «Выполнение программы».

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

В вашем примере добавление унарного + не влияет на наблюдаемое поведение, поэтому компилятор может его игнорировать.

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

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

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

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

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

Если предположить, что реализации действительно соответствуют, тогда вопрос должен заключаться не в том, действительно ли оценка выражения является переупорядочена, а скорее в том, разрешает ли C переупорядочивать ее в появляться. То есть мне кажутся наиболее актуальными требования поведения абстрактной машины. Для этого наиболее важной частью стандарта является Раздел 6.5.

Особенно:

The value computations of the operands of an operator are sequenced before the value computation of the result of the operator.

а также

The grouping of operators and operands is indicated by the syntax.

Учитывая ваше примерное выражение

a = (b + c) + d;

, то это указывает, что сначала оцениваются подвыражения (b + c) и d, а затем вычисляется их сумма. Более ранние версии стандарта имели похожую формулировку, особенно в последней части, и я считаю бесспорным, что поведение абстрактной машины, определяемое каждой версией стандарта, требует того же.

Если вы не можете отличить (до предела наблюдаемого поведения), то действительно ли вам важно, какое изменение порядка выполняется? Есть причины, по которым вы можете это сделать - например, время выполнения является самым большим, - но вы не должны слишком беспокоиться о правильности.

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

• Данные записываются в файлы.
• Динамика ввода и вывода интерактивных устройств.
• Доступ к летучим объектам.

Если исходный код оценивает (a+b)+c и распечатывает его (так, чтобы результат был наблюдаемым), реализация C должна выдать результат, аналогичный добавлению a и b, а затем добавлению c, но это не требуется для получения этого результата с помощью добавление a и b, а затем добавление c.

Однако стандарт C позволяет вычислять выражения с плавающей запятой с большей точностью и диапазоном экспонент, чем их номинальные типы (например, арифметика double может использоваться для выражений, содержащих только операнды float), и он не определяет точность, требуемую для чисел с плавающей запятой. -точечная арифметика и библиотечные процедуры. Если вас беспокоит точное поведение выражений с плавающей запятой, вы должны учитывать не только порядок оценки; вы должны учитывать качество и свойства используемой вами реализации C.

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

Стандарт C требует приведения или присваивания, чтобы «убрать» лишнюю точность. Итак, если вы напишете:

t = a+b;
printf("%.99g\n", t+c);

тогда компилятор должен выдать результат, как если бы (a+b)+c был оценен с некоторой точностью и затем округлен до своего номинального типа, а затем был добавлен c. Это может привести к ошибкам двойного округления, поскольку вычисление a+b с избыточной точностью может округляться таким образом, что последующее округление до номинального типа дает результат, отличный от добавления a+b только в номинальном типе.

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

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

Рассмотрим следующее (err, item и totalSum имеют тип double):

err = ((nextItem + totalSum) - totalSum) - nextItem;

Здесь мы находимся в цикле, суммирующем элементы массива элементов. ЕСЛИ приведенный выше оператор на самом деле выполняется точно так, как написано, "err" будет содержать биты, которые в противном случае "упали бы с конца" из-за с ограниченной точностью (totalSum больше, чем nextItem).

Абстрактная машина C требует, чтобы выражение было вычислено «как если бы» было вычислено, как написано. C обычно допускает промежуточное выражение, которое будет оцениваться с более высокой точностью, а затем последний результат округлен по размеру. К сожалению, абстрактная машина C имеет бесконечную точность. Это означает, что является законный / соответствующий для реализация для оптимизации приведенного выше выражения в:

err = 0.0;

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

Конкретная реализация мая выбирает реализацию более строгих правил об оценке выражений (и, по общему признанию, всех реальных реализациях do), например, чтобы соответствовать семантике IEEE 754, но это не требуется по стандарту C.

ОДНАКО, стандартный делает требует, чтобы при присвоении или приведение, рассматриваемое значение должно быть преобразовано в правильное введите в этот момент. На практике это нарушает бесконечную точность парадигма. Итак, если мы напишем выражение так:

double tmp = nextItem + totalSum;
tmp = tmp - totalSum;
err = tmp - nextItem;

Здесь стандартные гарантии, что мы делать получаем желаемый эффект, поскольку, когда мы назначаем подвыражение tmp, значение должно быть округлено до подходящего размера, поэтому прямая подстановка не позволяет отменить из условий. Мы могли бы даже сделать это как:

err = ((double)((double)(nextItem + totalSum)) - totalSum) - nextItem;

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

Действительно ли конкретная реализация Соответствие стандартам по этому поводу - это другой вопрос.