Niektóre typowe przypadki, w których kolejność oceny do tej pory nie została określona , są określone i ważne z C++17. Niektóre niezdefiniowane zachowania są teraz nieokreślone.
i = 1;
f(i++, i)
był nieokreślony, ale teraz jest nieokreślony. W szczególności nie określono kolejności, w jakiej każdy argument fjest oceniany względem innych. i++można ocenić wcześniej ilub odwrotnie. Rzeczywiście, może ocenić drugie wywołanie w innej kolejności, mimo że znajduje się w tym samym kompilatorze.
Jednak ocena każdego argumentu musi zostać wykonana w całości, ze wszystkimi skutkami ubocznymi, przed wykonaniem jakiegokolwiek innego argumentu. Więc możesz otrzymać f(1, 1)(drugi argument jest oceniany jako pierwszy) lub f(1, 2)(pierwszy argument jest oceniany jako pierwszy). Ale nigdy nie dostaniesz f(2, 2)ani niczego podobnego.
std::cout << f() << f() << f();
nie została określona, ale stanie się zgodna z priorytetem operatorów, tak że pierwsza ocena fbędzie miała miejsce jako pierwsza w strumieniu (przykłady poniżej).
f(g(), h(), j());
nadal ma nieokreśloną kolejność ocen g, h i j. Zauważ, że dla getf()(g(),h(),j()), reguły określają, że getf()będą oceniane wcześniej g, h, j.
Zwróć również uwagę na następujący przykład z tekstu oferty:
std::string s = "but I have heard it works even if you don't believe in it"
s.replace(0, 4, "").replace(s.find("even"), 4, "only")
.replace(s.find(" don't"), 6, "");
Przykład pochodzi z The C ++ Programming Language , 4th edition, Stroustrup i było wcześniej nieokreślonym zachowaniem, ale z C ++ 17 będzie działać zgodnie z oczekiwaniami. Podobne problemy występowały w przypadku funkcji wznawiania ( .then( . . . )).
Jako inny przykład rozważ następujące kwestie:
#include <iostream>
#include <string>
#include <vector>
#include <cassert>
struct Speaker{
int i =0;
Speaker(std::vector<std::string> words) :words(words) {}
std::vector<std::string> words;
std::string operator()(){
assert(words.size()>0);
if(i==words.size()) i=0;
auto word = words[i] + (i+1==words.size()?"\n":",");
++i;
return word;
}
};
int main() {
auto spk = Speaker{{"All", "Work", "and", "no", "play"}};
std::cout << spk() << spk() << spk() << spk() << spk() ;
}
Z C ++ 14 i zanim będziemy mogli (i będziemy) uzyskiwać wyniki takie jak
play
no,and,Work,All,
zamiast
All,work,and,no,play
Zauważ, że powyższe działa tak samo jak
(((((std::cout << spk()) << spk()) << spk()) << spk()) << spk()) ;
Ale nadal przed C ++ 17 nie było gwarancji, że pierwsze wywołania pojawią się jako pierwsze w strumieniu.
Referencje: Z zaakceptowanej propozycji :
Wyrażenia postfiksowe są oceniane od lewej do prawej. Obejmuje to wywołania funkcji i wyrażenia wyboru elementu członkowskiego.
Wyrażenia przypisania są oceniane od prawej do lewej. Obejmuje to zadania złożone.
Operandy do operatorów przesunięcia są obliczane od lewej do prawej. Podsumowując, poniższe wyrażenia są oceniane w kolejności a, następnie b, potem c, a następnie d:
- ab
- a-> b
- a -> * b
- a (b1, b2, b3)
- b @ = a
- a [b]
- a << b
- a >> b
Ponadto proponujemy następującą dodatkową regułę: kolejność oceny wyrażenia zawierającego przeciążony operator jest określona przez kolejność skojarzoną z odpowiednim operatorem wbudowanym, a nie przez reguły wywołań funkcji.
Uwaga dotycząca edycji: moja pierwotna odpowiedź została błędnie zinterpretowana a(b1, b2, b3). Kolejność b1, b2, b3nadal jest nieokreślony. (dziękuję @KABoissonneault, wszystkim komentującym.)
Jednak (jak @Yakk zaznacza) i to jest ważne: Nawet jeśli b1, b2, b3są wyrażeniami nietrywialne, każda z nich są całkowicie ocenione i przywiązany do odpowiedniego parametru funkcji zanim inni są te zaczęły być oceniane. Norma mówi tak:
§5.2.2 - Wywołanie funkcji 5.2.2.4:
. . . Wyrażenie postfiksowe jest sekwencjonowane przed każdym wyrażeniem na liście-wyrażeń i dowolnym argumencie domyślnym. Każde obliczenie wartości i efekt uboczny związany z inicjalizacją parametru oraz sama inicjalizacja są sekwencjonowane przed każdym obliczeniem wartości i efektem ubocznym związanym z inicjalizacją dowolnego kolejnego parametru.
Jednak jednego z tych nowych zdań brakuje w wersji roboczej GitHub :
Każde obliczenie wartości i efekt uboczny związany z inicjalizacją parametru oraz sama inicjalizacja są sekwencjonowane przed każdym obliczeniem wartości i efektem ubocznym związanym z inicjalizacją dowolnego kolejnego parametru.
Przykładem jest tam. Rozwiązuje problemy sprzed dziesięcioleci ( jak wyjaśnił Herb Sutter ) z wyjątkiem bezpieczeństwa
f(std::unique_ptr<A> a, std::unique_ptr<B> b);
f(get_raw_a(), get_raw_a());
przeciekałby, gdyby jedno z wywołań get_raw_a()zgłosiło się, zanim drugi surowy wskaźnik zostałby powiązany z jego parametrem inteligentnego wskaźnika.
Jak wskazał TC, przykład jest błędny, ponieważ konstrukcja unique_ptr z surowego wskaźnika jest jawna, co zapobiega kompilacji. *
Zwróć również uwagę na to klasyczne pytanie (oznaczone jako C , a nie C ++ ):
int x=0;
x++ + ++x;
jest nadal nieokreślona.