Как код ведет себя отличающийся для Java и компилятора C?

В C ++ результат является неопределенным, т. Е. Не указан и не гарантированно согласован - компилятор может делать все, что ему больше всего подходит, в любое время на основе точек последовательности ].

Я подозреваю, что то же самое для Java [и C # и т. Д.]

Что ж ... что вы считаете правильным и каковы ваши рассуждения?

Я считаю, что x довольно хорошо определено для первых трех шагов

x = 10
x is decremented (its initial value is used first)
x is decremented again (its resulting value is used after)

Теперь x == 8 . Но посмотрите, что вы делаете с этим здесь (простите за вставку удобных для человека пробелов):

x -= --x - x--

Которая может быть скомпилирована (это то, что я сделал бы, если бы у меня было , чтобы включить Операторы ++ и - на моем языке - сначала выявляются побочные эффекты и удаляются в начале и в конце инструкции в целом):

--x
t = x - x
x -= t
x--

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

t1 = --x     // t1 = 7, x = 7
t2 = x--     // t2 = 7, x = 6
t = t1 - t2  // t = 7 - 7 = 0
x -= t       // x = 6

Или подвыражения могли попасть в обратную сторону:

The fundamental difference between Java and C is that in C language the temporal relationships between different actions (what happens "before" and what happens "after") is determined by so called sequence points. Sequence points implement the concept of time in the process of execution of C program. If two actions are separated from each other by a sequence point, then you can say that one action happens "before" and another happens "after". When two actions have no sequence point between them, there's no defined temporal ordering between them and there's no way to say what happens "first" and what happens "later". Consider a pair of adjacent sequence points in C program as the minimal indivisible unit of time. What happens within that unit of time cannot be described in terms of "before" and "after". One might as well think that between two adjacent sequence points everything is happening simultaneously. Or in random order, whichever you prefer.

In C language the statement

x -= --x - x--;

has no sequence points inside. It only has a sequence point at the very beginning and at the very end. This means that there's no way to say in which order this expression statement is evaluated. It is indivisible it terms of C time, as described above. Every time someone tries to explain what happens here by imposing a specific temporal ordering, they are just wasting their time and producing utter nonsense. This is actually the reason why C language does not (and cannot) make any attempts to define the behavior of expressions with multiple modifications of the same object (x in the above example). The behavior is undefined.

Java is significantly different in this respect. In Java the concept of time is defined differently. In Java the expressions are always evaluated in strict order defined by the operator precedence and associativity. This imposes a strict temporal ordering on the events that take place during the evaluation of the above expression. This makes the result of this expression defined, as opposed to C.

Вы ошибаетесь, когда говорите, что вывод этого кода, рассматриваемого как программа C, равен 6 .

Рассматриваемая как программа C, это undefined . Вы просто случайно получили 6 с вашим компилятором, но с тем же успехом вы могли получить 24, ошибку сегментации или ошибку времени компиляции.

См. стандарт C99 , 6.5.2:

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

- xx - явно запрещено этим параграфом.

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

Аарон Дигулла пишет в комментариях:

Это действительно undefined?

Вы заметили, что я связался со стандартом C99 и указал параграф, в котором говорится, что это undefined?

gcc -Wall (GCC 4.1.2) не жалуется на это, и я сомневаюсь, что любой компилятор отклонил бы этот код.

Стандарт описывает некоторые варианты поведения как «неопределенные» именно потому, что не все способы, по которым программа на C является бессмысленной, могут быть надежно обнаружены во время компиляции. Если вы думаете, что "без предупреждения" должно означать, что все в порядке, вам следует переключиться на другой язык, кроме C. Многие современные языки определены лучше. Я использую OCaml , когда у меня есть выбор, но есть бесчисленное множество других четко определенных языков.

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

Я не заметил вашего объяснения того, почему это выражение оценивается как 6. Надеюсь, вы не тратьте слишком много времени на его написание, потому что для меня он возвращает 0.

Macbook:~ pascalcuoq$ cat t.c
#include <stdio.h>

int main(int argc, char **argv)
{
  int y;
  printf("argc:%d\n", argc);
  y = --argc - argc--;
  printf("y:%d\n", y);
  return 0;
}
Macbook:~ pascalcuoq$ gcc t.c
Macbook:~ pascalcuoq$ ./a.out 1 2 3 4 5 6 7 8 9
argc:10
y:0

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

Macbook:~ pascalcuoq$ gcc -v
Using built-in specs.
Target: i686-apple-darwin9
Configured with: /var/tmp/gcc/gcc-5490~1/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=i686-apple-darwin9 --with-arch=apple --with-tune=generic --host=i686-apple-darwin9 --target=i686-apple-darwin9
Thread model: posix
gcc version 4.0.1 (Apple Inc. build 5490)

Аарон также пишет:

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

Совершенно верно! Я дал простейшее объяснение, почему можно получить 6: результат явно указан в C99 как неопределенное поведение, и это было и в более ранних стандартах.

и:

Наконец, покажите, пожалуйста, компилятор, который предупреждает об этой конструкции.

Насколько мне известно, компилятор не предупреждает о * (& x - 1) , где x определяется как int x; . Вы утверждаете, что эта конструкция действительна на языке C и что хороший инженер должен уметь предсказать результат, потому что компилятор не предупреждает об этом? Эта конструкция не определена, как и обсуждаемая.

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

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

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

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

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

Я не знаю наверняка, но предполагаю, что это потому, что Java оценивает постдекремент на последнем x-- перед , оценивая оператор - =, тогда как C ++ вычисляет сначала - =, а постдекремент после выполнения всей остальной части выражения.