Вообще-то все логично. Знаете чем отличаются записи --х и х-- ? Нет? Почитайте.

раз логично, то объясните. Не можете?  Я об этом узнал (о том, КАК это происходит) лет 10 назад. Любопытно, что про сами префиксные/постфиксные операции я узнал лет на 5 раньше. Мне понадобилось читать мануалы примерно 5 лет... Такие дела...

А почему не логичный?
Мне кажется все достаточно логично и "человечно". У нас есть выражение разница двух чисел - не более. Но в этом же выражении (кроме получения нужного значения разницы) мы (точнее программер сунувший это в свой код) еще хотим сделать дополнительные действия с переменной x.

Т.е. это выражение означает, что мы хотим получить разницу между Х и (X-1) и логично получить 1.
Только X-- мы говорим, что хотим уменьшить х после того, как посчитаем это выражение.
Т.е. по человечески читаем с лева на право: 10 (потом надо будет уменьшить)  -  (10-1) = 1

Но вот где такое выражение могло бы быть применено я не представляю.

потому что многие считают, что получится 0 или 2. Т.е.
x-- == 10
--x == 9-1 == 8
- == 10-8 == 2

или
--x == 9
x-- == 9
- == 0

Здесь складывается впечатление, что компилятор зачем-то засунул первое x-- в самый конец выражения. (только так можно получить 1). Но это НЕ ТАК. На самом деле, при x--, переменная x расщепляется на две:
Первая часть уменьшается на 1, и соответствует "истинному x",
Вторая часть НЕ уменьшается, причём именно она и участвует в вычислениях.

Любопытно так-же и то, что операция --x на самом деле равносильна x = (x-1). Вот только одно но: в си нет конструкции языка "равно", за то есть арифметическая операция X=Y. Как у любой бинарной операции, у "=" есть:
1) операнды X, Y
2) результат, который равен Y
Но кроме этого, у равно есть и
3) побочный эффект - X становится равным Y.
В нашей ситуации, выражение на самом деле вычисляется так:
(x2 <= x, x1 <= x-1) // это операция х--
(x3 <= x2 - 1, x1 <= x2 - 1) // это операция --x, которую компилятор был вынужден поместить перед минусом, ибо её результат является аргументом вычитания, а старшинство -- выше. Потому компилятор поменял - и -- местами
Обратите внимание, что аргумент этой операции - "временная" величина, а результат (побочный) пишется естественно в "постоянную" x1. Это правило.
(x4 = x2 - x3) // вот тут и происходит собственно вычитание. Вычитается уменьшенное на 1 значение началной переменой, из самой переменной. Потому результат тождественно равен константе 1.

Само x получает сначала значение x-1, а потом, при неявной операции присваивания внутри --x, оно вторично получает значение x-1. Т.е., как и записано, происходит двойной инкремент, но он происходит дважды над одним и тем-же значением x.

Тут не один, а два "подвоха")

  Для начала, порядок операций в Си точно определен; для данного случая:

1. Префиксный декремент.
2. Вычисление выражения и возврат значения.
3. Постфиксный декремент.

  Т.е., например такой код:

#include <stdio.h>

int main()
{
    int x = 35;
    int y = 35;

    printf("\ny-- - --x = %d\n", y-- - --x);
    return 0;
}

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

  Для понимания ситуации, вот парочка примеров:

#include <stdio.h>

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

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


#include <stdio.h>
int main()
{
    int x = 133;
    printf("\nx-- - --x = %d\n", x-- - --x);
    return 0;
}

  Хоть компилер и пишет, что ситауция неопределенна, возвращает 0. Здравый смысл подсказывает, что x - одна переменная, и вычитается она сама из себя, и неважно, какие там декременты стоят.

  В случае же с кодом drBatty - это отдельная песня. Для начала, небольшой код:

#include <stdio.h>
int main()
{
    int x = 133;
    int* px = &x;
    printf("\nx-- - --x = %d\n", x-- - --x);
    return 0;

    int y = 133;
    printf("\ny-- - -y = %d\n", y-- - --y);
    return 0;
}

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

нет. в нём ЯВНО записано, что порядок НЕ ОПРЕДЕЛЁН.

ну а откуда тут неоднозначность-то? в каком порядке не считай, получится 1

│000003b3 ff4df0                         dec         dword ptr [ebp-00000010]
│000003b6 8b45f0                         mov         eax, [ebp-00000010]
│000003b9 8b55f4                         mov         edx, [ebp-0000000c]
│000003bc 29c2                           sub         edx, eax
│000003be ff4df4                         dec         dword ptr [ebp-0000000c]

первая команда может когда угодно делать y--, ибо её результат никого не волнует. Мало того, она его может и НЕ ДЕЛАТЬ, ибо всё равно вы y не используете.
А то, что вы юзаете константы - вообще...

0000040a 83e822                         sub         eax, 0x22

у вас просто не будет никаких вычислений!

мне всё равно, что подсказывает ваш здравый смысл. Стандарт намекает, что тут у вас константы, и программа не обязана их считать. и не считает, ЧСХ.

ссылка тут не причём. Можете задать x любым нетривиальным методом, например прочитав его с диска. А переменных конечно две - как может быть одна, если x-- имеет ДВА РЕЗУЛЬТАТА.

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

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

Дмитрий, обратите внимание, я сказал -- в 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 может быть константой равной нулю.

|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 всё намного запутаннее.

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

Newton, а какое там поведение? пробовать лень

вот холивар на пустом месте развели.... си всегда славился множеством UB и спорить по ним бесполезно... всегда можно создать компилятор, который будет возвращать 192 в данном случае. и это будет соответствовать стандарту. если нечем заняться, то давайте ещё будем думать, чему равно x=333; (x++ - --x) * ((&((char) x))[1]) << (x-=7);