фича компиляторв, инкремент переменной Опции

[zhevak]

На форуме программистов (здесь http://www.rsdn.ru/Forum/?mid=2481623) с пацанами сейчас подняли интересную тему. Думаю, что си-шникам тоже следует остерегаться подобного кода. В двух словах проблема состоит в том, как компилятор должен понимать оператор инкремента.

int i;
int x;

i = 5;
x = ++i + ++i;

Чему в результате будет равно х ?

Прикол в том, что MS VC++ 6.0 и VC++.NET дают результат, равный 14. Майкрософтовский C# и IAR говорят, что х = 13. А более всего удивил Watcom -- у него результат зависит от того, включена-ли оптимизация или нет...

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

Вечером дома, попробую еще в CodeVision эту фичу покрутить.

[vetal]

Потому и "undefined bihavior", что по моему мнению оператор + складывает 2 ячейки памяти с адресом I, а по вашему он заводит дополнительную переменную. Тут всё и кроется))

[Oldring]

Потому и "undefined bihavior", что по моему мнению оператор + складывает 2 ячейки памяти с адресом I, а по вашему он заводит дополнительную переменную. Тут всё и кроется))

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

Ваше мнение о том, "что оператор + складывает 2 ячейки памяти с адресом i" противоречит утверждению из стандарта, что результат вычисления ++i не есть lvalue. Так что такую интерпретацию принять не могу как "правильную"

Вся эта бодяга действительно отдана на откуп компилятору в зависимости от платформы. Но что интересно - в результате реального эксперимента все компиляторы для x86 платформы выдали тот самый результат, а под ARM и BF выдали warning - не смогли на штатном механизме обеспечить?
Интересный такой нюанс. Надо будет GNU на не на x86 платформе спытать.

arm-elf-gcc версии 4.1.1 выдает 13.

[zltigo]

arm-elf-gcc версии 4.1.1 выдает 13.

Молча?

[Oldring]

Молча?

По умолчанию - да.

В программе, приведенной ниже, с ключем -Wsequence-point выдается предупреждение "warning: operation on 'i' may be undefined" внутри main(), но не внутри f(). В обоих случаях - 13.

Код

int f( int* p1, int* p2 )
{
    return ++(*p1) + ++(*p2);
}

int main( void )
{
    int i;
    int x1, x2;

    i = 5;
    x1 = ++i + ++i;

    i = 5;
    x2 = f( &i, &i );

    return x2;
}

P.S. С включенной оптимизацией -O3 main своится к возврату 13.

[zltigo]

В программе, приведенной ниже, с ключем -Wsequence-point выдается предупреждение "warning: operation on 'i' may be undefined" внутри main(), но не внутри f(). В обоих случаях - 13.

Ну про f() это естественно правильно - по другому было-бы крайне странно. С main() выдал warning расписавшись в непонятках - тоже каой-же после этого спрос.

Зксперименировал для начала с OpenWatcom...

P.S. С включенной оптимизацией -O3 main своится к возврату 13.

Аналогично. C приличными оптимизациями все сводится к

Код

    push      0000000eH
    push      offset FLAT:L$402
    call      near ptr FLAT:printf_
    add       esp,00000008H
    ret

Пришлось извне передавать.

Код

void dummy( int i )
{
int k = ++i + ++i;
    printf( "k=%i\r", k );
}

Это вариант с разнообразными оптимизаторами:

Код

    add       eax,00000002H
    add       eax,eax
    push      eax
    push      offset FLAT:L$402
    call      near ptr FLAT:printf_
    add       esp,00000008H
    ret

и вообще без оптимизации:

Код

    push      00000030H
    call      near ptr FLAT:__CHK
    push      ebx
    push      ecx
    push      edx
    push      esi
    push      edi
    push      ebp
    mov       ebp,esp
    sub       esp,0000000cH
    mov       dword ptr -0cH[ebp],eax
    inc       dword ptr -0cH[ebp]
    inc       dword ptr -0cH[ebp]
    mov       eax,dword ptr -0cH[ebp]
    add       eax,dword ptr -0cH[ebp]
    mov       dword ptr -4H[ebp],eax
    push      dword ptr -4H[ebp]
    mov       eax,offset FLAT:L$450
    push      eax
    call      near ptr FLAT:printf_
    add       esp,00000008H
    mov       esp,ebp
    pop       ebp
    pop       edi
    pop       esi
    pop       edx
    pop       ecx
    pop       ebx
    ret

Но при любых уровнях оптимизации "неизменно превосходный результат". warnin-ов нет. Причем, что действительно интересно даже в вырожденном случае с тупым возвратом значения , где уже все заранее решено - 14.

И говорит что так делать нельзя.

В обоих случаях оптимизации говорит нельзя?

[Oldring]

Но при любых уровнях оптимизации "неизменно превосходный результат". warnin-ов нет. Причем, что действительно интересно даже в вырожденном случае с тупым возвратом значения , где уже все заранее решено - 14.

В любом случае, это не есть доказательство "правильности" значения 14.

Ну про f() это естественно правильно - по другому было-бы крайне странно. С main() выдал warning расписавшись в непонятках - тоже каой-же после этого спрос.

gcc на x86 неизменно возвращает 14. в том числе, из f()

[zltigo]

В любом случае, это не есть доказательство "правильности" значения 14.

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

gcc на x86 неизменно возвращает 14. в том числе, из f()

Я мельком глянул на f() - естественно ошибся .