W praktyce, dlaczego różne Kompilatory obliczają różne wartości int x = ++i + ++i;?

Chociaż jest to UB (jak sugeruje OP), poniżej przedstawiono hipotetyczne sposoby, w jakie kompilator może uzyskać 3 wyniki. Wszystkie trzy dałyby ten sam poprawny wynik x, jeśli są używane z różnymi zmiennymi int i = 1, j = 1; zamiast jednej i tej samej i.

1. oba ++zwracam 2, co daje x = 4.

int i = 1;
int i1 = i, i2 = i;   // i1 = i2 = 1
++i1;                 // i1 = 2
++i2;                 // i2 = 2
int x = i1 + i2;      // x = 4

1. jeden ++i zwraca 2, a drugi zwraca 3, co daje x=5.

int i = 1;
int i1 = ++i;           // i1 = 2
int i2 = ++i;           // i2 = 3
int x = i1 + i2;        // x = 5

1. zarówno ++zwracam 3, co powoduje x=6.

int i = 1;
int &i1 = i, &i2 = i;
++i1;                   // i = 2
++i2;                   // i = 3
int x = i1 + i2;        // x = 6

Dla mnie druga wydaje się najbardziej prawdopodobna.

Wybieram opcję # 4: obie ++i zdarzają się jednocześnie.

Nowsze procesory idą w kierunku ciekawych optymalizacji, a równoległa ocena kodu, gdzie jest dozwolona, jest kolejnym sposobem kompilatorów na tworzenie szybszego kodu. Ja widzę jako praktyczną implementację Kompilatory idące w kierunku równoległości.

Mogłem łatwo zobaczyć stan wyścigu powodujący niedeterministyczne zachowanie lub awarię autobusu z powodu tego samego spór o pamięć - wszystko dozwolone, ponieważ koder naruszył umowę C++ - stąd UB.

Moje pytanie brzmi: jakie (rozsądne) rzeczy mógłby zrobić kompilator C++, który doprowadziłby do wyniku 4 lub wyniku 6?

To może , ale nie liczy się w nim.

Nie używaj ++i + ++i ani nie oczekuj sensownych rezultatów.

Myślę, że prosta i prosta interpretacja (bez żadnej oferty na optymalizację kompilatora lub wielowątkowość) byłaby po prostu:

1. Increment i
2. Increment i
3. dodaj i + i

Z i zwiększoną dwukrotnie, jego wartość wynosi 3, a po zsumowaniu suma wynosi 6.

Dla kontroli, rozważ to jako funkcję C++:

int dblInc ()
{
    int i = 1;
    int x = ++i + ++i;
    return x;   
}

Oto kod asemblera, który otrzymuję ze kompilacji tej funkcji, używając stara wersja kompilatora GNU C++ (win32, gcc w wersji 3.4.2 (MinGW-special)). Nie ma tu fantazyjnych optymalizacji ani wielowątkowości:

__Z6dblIncv:
    push    ebp
    mov ebp, esp
    sub esp, 8
    mov DWORD PTR [ebp-4], 1
    lea eax, [ebp-4]
    inc DWORD PTR [eax]
    lea eax, [ebp-4]
    inc DWORD PTR [eax]
    mov eax, DWORD PTR [ebp-4]
    add eax, DWORD PTR [ebp-4]
    mov DWORD PTR [ebp-8], eax
    mov eax, DWORD PTR [ebp-8]
    leave
    ret

Zauważ, że zmienna lokalna i znajduje się na stosie w jednym miejscu: address [ebp-4]. Ta lokalizacja jest zwiększana dwukrotnie(w 5.-8. linii funkcji assembly; włączając pozornie nadmiarowe ładunki tego adresu do eax). Następnie w 9-tych-dziesiątych liniach wartość ta jest ładowana do eax, a następnie dodawana do eax (czyli oblicza prąd i + i). Następnie jest on redundantnie kopiowany do stosu i z powrotem do eax jako wartość zwracana (która oczywiście będzie równa 6).

Z wyjątkiem sytuacji, gdy zaznaczono, kolejność ocen poszczególnych operandów operatory i podekspresje poszczególnych wyrażeń, a kolejność w których skutki uboczne biorą miejsce, jest nieokreślony.

Z przypisem:

Pierwszeństwo operatorów nie jest bezpośrednio określone, ale może być pochodzi ze składni.

Dwa przykłady nieokreślonego zachowania są podane w tym momencie, oba z udziałem operatora przyrostu (z których jeden to: i = ++i + 1).

Teraz, gdyby ktoś chciał, można: utworzyć klasę owijania liczb całkowitych (jak Java Integer); funkcje przeciążające operator+ i operator++ takie, że zwracają obiekty wartości pośredniej; i tym samym napisać {[17] } i uzyskać go, aby zwrócić obiekt posiadający 5. (Nie zamieściłem tu pełnego kodu ze względu na zwięzłość.)

Osobiście byłbym zaintrygowany, gdyby był przykład znanego kompilatora, który wykonał to zadanie w inny sposób niż Sekwencja pokazana powyżej. Wydaje mi się, że najprostszą implementacją byłoby wykonanie dwóch asemblerów incna prymitywnym typie przed wykonaniem operacji dodawania.

Rozsądną rzeczą, jaką może zrobić kompilator, jest wspólna eliminacja Podekspresji. Jest to już powszechna optymalizacja w kompilatorach: jeśli podwyrażenie takie jak (x+1) występuje więcej niż raz w większym wyrażeniu, musi być obliczone tylko raz. Np. w a/(x+1) + b*(x+1) pod-wyrażenie x+1 można obliczyć raz.

Oczywiście kompilator musi wiedzieć, które pod-wyrażenia można zoptymalizować w ten sposób. Wywołanie rand() dwa razy powinno dać dwie losowe liczby. Nieinlinowane wywołania funkcji muszą w związku z tym są zwolnione z CSE. Jak zauważyłeś, nie ma reguły, która mówi, jak dwa wystąpienia i++ powinny być obsługiwane, więc nie ma powodu, aby zwolnić je z CSE.

Wynik może być rzeczywiście taki, że int x = ++i + ++i; jest zoptymalizowany do int __cse = i++; int x = __cse << 1. (CSE, po którym następuje wielokrotna redukcja siły)

W praktyce wywołujesz nieokreślone zachowanie. Wszystko może się zdarzyć, nie tylko rzeczy, które uważasz za "rozsądne", i często rzeczy robią zdarzają się, które nie uważasz za rozsądne. Wszystko jest z definicji "rozsądne".

Bardzo rozsądną kompilacją jest to, że kompilator zauważa, że wywołanie instrukcji wywoła niezdefiniowane zachowanie, dlatego instrukcja nie może zostać wykonana, dlatego jest tłumaczona na instrukcję, która celowo zawiesza działanie podanie. To bardzo rozsądne.

Downvoter: GCC zdecydowanie się z tobą nie zgadza.

Nie ma rozsądnej rzeczy, którą kompilator mógłby zrobić, aby uzyskać wynik 6, ale jest to możliwe i uzasadnione. Wynik 4 jest całkowicie rozsądny, a ja uważam wynik 5 za rozsądny. Wszystkie są całkowicie legalne.

ast.cpp:4:9: warning: multiple unsequenced modifications to 'i' [-Wunsequenced]
int x = ++i + ++i;
        ^     ~~
(some lines omitted)
`-CompoundStmt 0x2b3e628 <line:2:1, line:5:1>
  |-DeclStmt 0x2b3e4b8 <line:3:1, col:10>
  | `-VarDecl 0x2b3e430 <col:1, col:9> col:5 used i 'int' cinit
  |   `-IntegerLiteral 0x2b3e498 <col:9> 'int' 1
  `-DeclStmt 0x2b3e610 <line:4:1, col:18>
    `-VarDecl 0x2b3e4e8 <col:1, col:17> col:5 x 'int' cinit
      `-BinaryOperator 0x2b3e5f0 <col:9, col:17> 'int' '+'
        |-ImplicitCastExpr 0x2b3e5c0 <col:9, col:11> 'int' <LValueToRValue>
        | `-UnaryOperator 0x2b3e570 <col:9, col:11> 'int' lvalue prefix '++'
        |   `-DeclRefExpr 0x2b3e550 <col:11> 'int' lvalue Var 0x2b3e430 'i' 'int'
        `-ImplicitCastExpr 0x2b3e5d8 <col:15, col:17> 'int' <LValueToRValue>
          `-UnaryOperator 0x2b3e5a8 <col:15, col:17> 'int' lvalue prefix '++'
            `-DeclRefExpr 0x2b3e588 <col:17> 'int' lvalue Var 0x2b3e430 'i' 'int'

Istnieje reguła :

Pomiędzy poprzednim i następnym punktem sekwencji obiekt skalarny musi mieć jego przechowywana wartość zmodyfikowana co najwyżej raz przez ocenę wyrażenie, w przeciwnym razie zachowanie jest nieokreślone.

Zatem nawet x = 100 jest możliwym poprawnym wynikiem.

Dla mnie najbardziej logiczny wynik w przykładzie to 6, ponieważ zwiększamy wartość i dwa razy i dodajemy ją do siebie. Trudno jest zrobić dodanie przed obliczeniami wartości z obu stron"+".

Ale programiści kompilatora mogą zaimplementować dowolną inną logikę.

Wygląda na to, że ++i zwraca wartość lvalue, ale i++ zwraca wartość rvalue.
Więc ten kod jest ok:

int i = 1;
++i = 10;
cout << i << endl;

Ten nie jest:

int i = 1;
i++ = 10;
cout << i << endl;

Powyższe dwa wyrażenia są zgodne z VisualC++, GCC7. 1. 1, CLang i Embarcadero.
Dlatego Twój kod w VisualC++ i GCC7.1.1 jest podobny do następującego

int i = 1;
... do something there for instance: ++i; ++i; ...
int x = i + i;

Kiedy patrzymy na demontaż, najpierw inkrementuje i, przepisuje i. gdy próbuje dodać robi to samo, inkrementuje i i przepisuje go. Następnie dodaje i do i.

Zauważyłem, że CLang i Embarcadero zachowują się inaczej. Nie jest to więc zgodne z pierwszą instrukcją, po first ++i zapisuje wynik w wartości R, a następnie dodaje go do second i++.

Osobiście nigdy bym się nie spodziewał, że kompilator wypowie 6 w twoim przykładzie. Są już dobre i szczegółowe odpowiedzi na twoje pytanie. Spróbuję krótkiej wersji.

Zasadniczo, {[0] } jest procesem dwuetapowym w tym kontekście:

1. zwiększ wartość i
2. odczytaj wartość i

W kontekście ++i + ++i obie strony dodawania mogą być oceniane W dowolnej kolejności zgodnie z normą. Oznacza to, że dwie przyrosty są uważany za niezależny. Ponadto nie ma zależności między tymi dwoma terminami. Przyrost i odczyt i mogą być zatem przeplatane. Daje to potencjalny porządek:

1. przyrost i dla lewego operandu
2. przyrost i dla prawego operanda
3. Read back i for the left operand
4. Read back i for the right operand
5. suma dwóch: daje 6

Teraz, gdy myślę o tym, 6 ma największy sens według standard. Dla wyniku 4 potrzebujemy PROCESORA, który najpierw odczytuje i niezależnie, a następnie zwiększa i zapisuje wartość z powrotem w tym samym miejscu; w zasadzie warunek race. Dla wartości 5 potrzebujemy kompilatora, który wprowadza tymczasowe.

Ale standard mówi, że ++i zwiększa zmienną przed jej zwróceniem, tzn. przed rzeczywistym wykonaniem bieżącej linii kodu. Operator sumy + musi sumować i + i po zastosowaniu przyrostów. Powiedziałbym, że C++ musi działać na zmiennych, a nie na wartości semantycznej. Stąd dla mnie 6 ma teraz największy sens, ponieważ opiera się na semantyce języka, a nie na modelu wykonawczym procesorów.

#include <stdio.h>


void a1(void)
{
    int i = 1;
    int x = ++i;
    printf("i=%d\n",i);
    printf("x=%d\n",x);
    x = x + ++i;    // Here
    printf("i=%d\n",i);
    printf("x=%d\n",x);
}


void b2(void)
{
    int i = 1;
    int x = ++i;
    printf("i=%d\n",i);
    printf("x=%d\n",x);
    x = i + ++i;    // Here
    printf("i=%d\n",i);
    printf("x=%d\n",x);
}


void main(void)
{
    a1();
    // b2();
}

Cóż to zależy od konstrukcji kompilatora.Dlatego odpowiedź będzie zależeć od sposobu dekodowania instrukcji przez kompilator.Używanie dwóch różnych zmiennych ++x I ++y zamiast stworzenie logiki byłoby lepszym wyborem. Uwaga:ouput zależy od wersji najnowszej wersji języka w ms visual studio, jeśli jego updated.So jeśli reguły się zmieniły, to wyjście

Spróbuj Tego

int i = 1;
int i1 = i, i2 = i;   // i1 = i2 = 1
++i1;                 // i1 = 2
++i2;                 // i2 = 2
int x = i1 + i2;      // x = 4

Z tego linku Kolejność oceny :

Kolejność oceny operandów dowolnego operatora C, w tym kolejność oceny argumentów funkcji w wywołaniu funkcji wyrażeń, a kolejność oceny podwyrażeń w obrębie każde wyrażenie jest nieokreślone(z wyjątkiem przypadków zaznaczonych poniżej). kompilator oceni je w dowolnej kolejności i może wybrać inne zamówienie, gdy to samo wyrażenie jest obliczane ponownie .

From, the quotes, it is jasne, że kolejność oceny nie jest określona przez standardy C. Różne Kompilatory implementują różne rozkazy ewalauacji. Kompilator może dowolnie oceniać takie wyrażenia w dowolnej kolejności. Dlatego różne Kompilatory dają różne wyniki dla wyrażeń wymienionych w pytaniu.

Ale jeśli punkt sekwencji jest obecny pomiędzy podwyrażeniami Exp1 i Exp2, to zarówno obliczanie wartości, jak i efekty uboczne Exp1 są sekwencjonowane-przed każdym obliczaniem wartości i poboczem efekt Exp2.

W praktyce powołujesz się na nieokreślone zachowanie. Wszystko może się zdarzyć, nie tylko rzeczy, które uważasz za "rozsądne", i często rzeczy robią zdarzają się, które nie uważasz za rozsądne. Wszystko jest z definicji "rozsądne".

Bardzo rozsądną kompilacją jest to, że kompilator zauważa, że wywołanie instrukcji wywoła nieokreślone zachowanie, dlatego instrukcja nie może być kiedykolwiek wykonana, dlatego jest tłumaczona na instrukcję, która celowo ulega awarii Twoje podanie. To bardzo rozsądne. W końcu kompilator wie, że ta awaria nigdy się nie wydarzy.