0,1, и 3.

s/0,1, и 3/0,1, и 2/
fixed

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

не. в данном случае стандарт хоть и не определяет точно решение, но какие-то рамки есть.
1) тут три операции, потому мы имеем не более 6и перестановок.
2) 3 из 6 перестановок нам не подходят, ибо по стандарту -- старше - и должно вычисляться раньше.
ну и получаем мы всего 3 ответа 0,1, и 3.

уволить быдлокодера и переписать строку по человечески? не?
просто вы видите, что это быдлокод, и я вижу. А сам быдлокодер - не видит. Вот для него эта тема и создавалась - что-бы видел, какая НЁХ получается.

Т.е., ведет себя так, будто х - это две разных переменных.

угу. на самом деле, такое поведение давно, со времён iP1 - когда в нём две трубы появилось - вот компилятор и старается раздвоить поток. Конечно он не рассчитан на мой быдлокод, но в других случаях команды спариваются, и выполняются одновременно.

    int x;
    printf("Введите число: ");
    scanf("%d", &x);

    printf("\nx-- - --x = %d\n", x-- - --x);
    return 0;

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

  Такой же коде:

    int i;
    printf("Введите число: ");
    scanf("%d", &i);

    int x = i;
    printf("\nx-- - --x = %d\n", x-- - --x);
    return 0;

  Ведет себя так, как я показал выше. И это справедливо только для gcc, MSVC как раз возвращает ноль при любом варианте.

Тут и начинается неоднозначность - компилер пытается разделить её на две, при этом не забывая, что переменная все-таки одна.

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

префикс-декремент , вычитание и возврат результата (0), пост-декремент.

ну выходит так

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

( Если я неправ - доказательства в студию!)

|0000040b 8b45f4                         mov         eax, [ebp-0000000c]   // X1 <= x  | 10                                         
│0000040e 8b55f4                         mov         edx, [ebp-0000000c]  //  X2 <= x | 10
│00000411 4a                             dec         edx  // X2 = X2 - 1 | 9
│00000412 8955f4                         mov         [ebp-0000000c], edx  //  x <= X2 | 9
│00000415 8b55f4                         mov         edx, [ebp-0000000c]  //  X2 <= x (sic!)
│00000418 89c1                           mov         ecx, eax  // X3 <= X1 | 10
│0000041a 29d1                           sub         ecx, edx  //  X3 <= X3 - X2 | 10-9==1
│0000041c 89ca                           mov         edx, ecx  //  X2 <= X3 | 1
│0000041e 48                             dec         eax // X1 <= X1 - 1 | 9                                                                    
│0000041f 8945f4                         mov         [ebp-0000000c], eax  // x <= X1 | 9

кстати, если я не ошибаюсь, MSVC делал также.

такое не будет. но IRL всё намного запутаннее.

Мой пример как раз и ценен тем, что у меня x раздваивается

  Это то, что я и пытался сказать, только другими словами. Когда я говорил про одну переменную, это означало - одну, явно объявленную программистом переменную.
 
  Тут и начинается неоднозначность - компилер пытается разделить её на две, при этом не забывая, что переменная все-таки одна.
 
  Если брать реальный компилятор (а не то что написано в стандарте), то его поведение вполне понятно - он вычитает переменную саму из себя.
( Если я неправ - доказательства в студию!)
 
  int x = 3;
  int y = x-- - --x;
 
  y = 0 = 2-- - 2;
  x = 1;
 
  Т.е., префикс-декремент , вычитание и возврат результата (0), пост-декремент. Тоже, само с вариантом:
 
  int x = 3;
  int y = x++ + ++x;
 
  Порядок такой: преф-инкремент, сложение и возврат результата (8), пост-инкремент.
 
  y = 8 = 4++ + 4;
  x = 5;

------------------------------------------------------------------------------
  Что же касается использования в рабочем коде.. какой же ССЗБ будет такое использовать? А если уж так хочется, то можно сделать что-нибудь вроде:
x = function() * (y+1);

обратите внимание, я сказал -- в C/C++ (1) и С# (2)

а... извините. что такое C# - без понятия.

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

нет и раздвоения - ибо в вашем выражении участвет только одно Y.

Мой пример как раз и ценен тем, что у меня x раздваивается, причём операция --x читает одну переменную х1, а пишет вторую - х2. Потому и получается столь неожиданный результат. ибо x--, --x вычтет из x двойку, а не единицу. А x-- - --x вычитает таки единицу.

угу. 2*2 всегда равно 4. Ну и что тут интересного и полезного?

В моём случае - важно. Ибо, если у вас есть функция, которая работает 1 час, то её выпадение вы заметите (программа будет работать на 1 час быстрее), и выпадение будет, когда оптимизирующий компилятор умножит эту функцию на x-- - --x, или любое другое выражение, которое тождественно равно нулю (если конечно у компилятора хватит ума распарсить, что x-- - --x может быть равно нулю). Заметьте, тут нет условий, просто умножение

x = function() * y;

компилируется в

x = 0;

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

  int x, y;

  printf("give me a number x: ");
  scanf("%d", &x);

  printf("give me a number y: ");
  scanf("%d", &y);

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

Что изменится? Результат все равно один.
 

  Когда переменных две, нет никакой неоднозначности.

  В данном случае, не важно когда они вычисляются.

zhevak, да что вы говорите?!

 Консоль:

ksu@ksu:~/test$ cat zh.c
...
x++ + ++x =8

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

Дмитрий, обратите внимание, я сказал -- в C/C++ (1) и С# (2)

А остальное, извините, комментировать не буду. (Помолчу-ка я лучше в тряпочку какое-то время ...)

Я эту тему поднимал лет пять назад не то на rsdn.ru

эта тема неоднократно поднималась в FIDO задолго до этого 

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

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

ЗЫЖ повторяю - константы не вычисляются в runtime!

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