Jest to nieokreślone zachowanie, a nie (tylko) nieokreślone zachowanie, ponieważ istnieją dwa zapisy do i bez interweniującego punktu sekwencji. Tak jest z definicji w zakresie, w jakim określa to norma.

Standard pozwala kompilatorom generować kod, który opóźnia zapis do pamięci masowej - lub z innego punktu widzenia, aby ponownie odtworzyć instrukcje implementujące efekty uboczne-w dowolny sposób, o ile jest zgodny z wymaganiami punktów sekwencji.

Problem z wyrażenie to oznacza, że implikuje dwa zapisy do i bez interweniującego punktu sekwencji:

i = i++ + 1;

Jeden zapis jest dla wartości pierwotnej i "plus jeden", a drugi jest dla tej wartości" plus jeden " ponownie. Te zapisy mogą się zdarzyć w dowolnej kolejności lub wybuchnąć całkowicie, o ile standard pozwala. Teoretycznie daje to nawet implementacjom swobodę wykonywania pakietów zapisów równolegle, bez konieczności sprawdzania jednoczesnych błędów dostępu.

C / C++ definiuje pojęcie o nazwie sequence points , które odnosi się do punktu w wykonaniu, w którym gwarantuje się, że wszystkie efekty poprzednich ocen zostaną już wykonane. Powiedzenie i = ++i + 1 jest niezdefiniowane, ponieważ zwiększa i i przypisuje i sobie, z których żaden nie jest zdefiniowanym punktem sekwencji. Dlatego nie jest sprecyzowane, co stanie się pierwsze.

Aktualizacja dla C++11 (30.09.2011)

Stop , jest to dobrze zdefiniowane W C++11. Nie został zdefiniowany tylko w C++03, ale C++11 jest bardziej elastyczny.

int i = 0;
i = ++i + 1;

Po tej linii, i będzie 2. Powodem tej zmiany było ... ponieważ to już działa w praktyce i byłoby więcej pracy, aby to było undefined niż po prostu zostawić to zdefiniowane w zasadach C++11 (faktycznie, że to działa teraz jest bardziej wypadkiem niż celową zmianą, więc proszę nie rób tego w swoim kodzie!).

Prosto z paszczy konia

Http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#637

Biorąc pod uwagę dwie opcje: zdefiniowaną lub nieokreśloną, którą byś wybrał?

Autorzy standardu mieli dwie możliwości: zdefiniować zachowanie lub określić je jako niezdefiniowane.

Biorąc pod uwagę wyraźnie niemądry charakter pisania takiego kodu, nie ma sensu określać dla niego wyniku. Można by zniechęcić do takiego kodu, a nie go zachęcać. To nie jest użyteczne ani konieczne do niczego.

Ponadto komitety normalizacyjne nie mają możliwości zmuszać autorów kompilatorów do robienia czegokolwiek. Gdyby wymagali określonego zachowania, prawdopodobnie wymóg ten zostałby zignorowany.

Są też powody praktyczne, ale podejrzewam, że były one podporządkowane powyższej ogólnej ocenie. Ale dla przypomnienia, wszelkie zachowania wymagane dla tego rodzaju wyrażeń i pokrewnych typów ograniczą zdolność kompilatora do generowania kodu, uwzględniania wspólnych podwyrażeń, przenoszenia obiektów między rejestrami i pamięcią itp. C był już utrudniony przez słabe ograniczenia widoczności. Języki takie jak Fortran dawno temu zdały sobie sprawę, że aliasowane parametry i globale były zabójcą optymalizacji i wierzę, że po prostu zabronili ich.

Ważną częścią standardu jest:

Jego przechowywana wartość zmodyfikowana co najwyżej raz przez ewaluację wyrażenia

Zmieniasz wartość dwukrotnie, raz operatorem++, raz przyporządkowaniem

Pamiętaj, że twoja kopia standardu jest nieaktualna i zawiera znany (i naprawiony) błąd tylko w pierwszej i trzeciej linijce kodu twojego przykładu, zobacz:

C++ Standard core Language Issue spis treści, rewizja 67, #351

I

Andrew Koenig: Sequence point error: unspecified or undefined?

Temat nie jest łatwy do odczytania po prostu standard (co jest dość niejasne : (w tym przypadku).

Na przykład, czy będzie dobrze (lub not) - zdefiniowane, nieokreślone lub inaczej w ogólnym przypadku w rzeczywistości zależy nie tylko od struktury instrukcji, ale także od zawartości pamięci (mówiąc konkretnie, wartości zmiennych) w momencie wykonania, inny przykład:

++i, ++i; //ok

(++i, ++j) + (++i, ++j); //ub, see the first reference below (12.1 - 12.3)

Proszę spojrzeć na (ma wszystko jasne i precyzyjne):

JTC1 / SC22 / WG14 N926 "Sequence Point Analysis"

Również Angelika Langer ma artykuł na ten temat (choć nie tak jasny jak poprzedni):

"punkty sekwencji i Ocena ekspresji w C++"

Była też dyskusja po rosyjsku (choć z pozornie błędnymi stwierdzeniami w komentarzach i w samym poście):

"Точки следования (punkty sekwencji)"

Poniższy kod pokazuje, jak można uzyskać zły (nieoczekiwany) wynik:

int main()
{
  int i = 0;
  __asm { // here standard conformant implementation of i = ++i + 1
    mov eax, i;
    inc eax;
    mov ecx, 1;
    add ecx, eax;
    mov i, ecx;

    mov i, eax; // delayed write
  };
  cout << i << endl;
}

W rezultacie wyświetli 1.

Zakładając, że pytasz " dlaczego język jest tak zaprojektowany?".

Mówisz, że i = ++i + i jest "oczywiście niezdefiniowany", ale i = ++i + 1 powinieneś zostawić i z określoną wartością? Szczerze mówiąc, to nie byłoby zbyt konsekwentne. Wolę mieć albo wszystko idealnie zdefiniowane, albo wszystko konsekwentnie nieokreślone. W C++ mam to drugie. Nie jest to strasznie zły wybór per se - po pierwsze, uniemożliwia pisanie złego kodu, który wprowadza pięć lub sześć modyfikacji w tym samym "oświadczenie".

Argument przez analogię: Jeśli myślisz o operatorach jako rodzajach funkcji, to ma to sens. Jeśli masz klasę z przeciążonym operator=, twoje polecenie przypisania byłoby równoważne z czymś takim:

operator=(i, ++i+1)

(pierwszy parametr jest przekazywany pośrednio przez wskaźnik this, ale jest to tylko dla ilustracji.)

Dla zwykłego wywołania funkcji jest to oczywiście niezdefiniowane. Wartość pierwszego argumentu zależy od tego, kiedy drugi argument jest oceniany. Jednak w przypadku typów prymitywnych ujdzie ci to na sucho, ponieważ oryginalna wartość i jest po prostu nadpisana; jej wartość nie ma znaczenia. Ale jeśli wykonywałbyś jakąś inną magię w swoim własnym operator=, wtedy różnica mogłaby się ujawnić.

Mówiąc najprościej: wszystkie operatory działają jak funkcje i dlatego powinny zachowywać się zgodnie z tymi samymi pojęciami. Jeśli {[5] } jest niezdefiniowana, to i = ++i również powinna być niezdefiniowana.

A może zgodzimy się, że nigdy, nigdy, nie napiszemy takiego kodu? Jeśli kompilator nie wie, co chcesz zrobić, jak możesz oczekiwać, że biedny sap, który podąża za tobą, zrozumie, co chcesz zrobić? Umieszczenie i++; na jego własnej linii spowoduje , a nie zabicie Cię.

Powodem jest sposób, w jaki kompilator obsługuje odczyt i Zapis wartości. Kompilator może przechowywać wartość pośrednią w pamięci i zatwierdzać ją tylko na końcu wyrażenia. Odczytujemy wyrażenie ++i jako "increase i by one and return it", ale kompilator może zobaczyć je jako " load the value of i, add one, return it, and the commit it back to memory zanim ktoś użyje go ponownie. Kompilator jest zachęcany do unikania czytania/pisania do rzeczywistej lokalizacji pamięci tak bardzo, jak to możliwe, ponieważ spowolniłoby to program.

W konkretnym przypadku i = ++i + 1 cierpi w dużej mierze z powodu potrzeby spójnych zasad zachowania. Wiele kompilatorów zrobi 'właściwą rzecz' w takiej sytuacji, ale co, jeśli jeden z i s był rzeczywiście wskaźnikiem, wskazującym na i? Bez tej reguły kompilator musiałby być bardzo ostrożny, aby upewnić się, że wykonuje ładunki i przechowuje w odpowiedniej kolejności. Zasada ta pozwala na więcej możliwości optymalizacji.

Podobny przypadek dotyczy tzw. zasady strict-aliasing. Nie można przypisać wartości (powiedzmy, an int) poprzez wartość niepowiązanego typu (powiedzmy, a float) z kilkoma wyjątkami. To sprawia, że kompilator nie musi się martwić, że niektóre float * używane zmieni wartość int i znacznie zwiększa potencjał optymalizacji.

Problem polega na tym, że standard pozwala kompilatorowi na całkowitą zmianę kolejności instrukcji podczas jej wykonywania. Nie wolno jednak zmieniać kolejności poleceń (o ile taka zmiana kolejności skutkuje zmianą zachowania programu). Dlatego wyrażenie i = ++i + 1; można oceniać na dwa sposoby:

++i; // i = 2
i = i + 1;

Lub

i = i + 1;  // i = 2
++i;

Lub

i = i + 1;  ++i; //(Running in parallel using, say, an SSE instruction) i = 1

Jest to jeszcze gorsze, gdy masz typy zdefiniowane przez użytkownika rzucane w mix, gdzie operator ++ może mieć jakikolwiek wpływ na typ autor rodzaju chce, w którym to przypadku kolejność zastosowana w ocenie ma istotne znaczenie.

I = v [i++]; / / zachowanie jest nieokreślone
i = ++i + 1; / / zachowanie jest nieokreślone

Wszystkie powyższe wyrażenia wywołują nieokreślone zachowanie.

I = 7, i++, I++; / / i staje się 9

Przeczytaj Steve Summit ' S C-FAQs.

Z ++i, muszę przypisać "1", ale z i = ++i + 1, musi być przypisana wartość "2". Ponieważ nie ma interwałowego punktu sekwencji, kompilator może założyć, że ta sama zmienna nie jest zapisywana dwa razy, więc te dwie operacje mogą być wykonywane w dowolnej kolejności. więc tak, kompilator byłby poprawny, Jeśli ostateczna wartość to 1.