Деякі типові випадки, коли порядок оцінки до цього часу не був визначений , вказані та діють за допомогою C++17. Деяка невизначена поведінка зараз не визначена.
i = 1;
f(i++, i)
було невизначеним, але зараз не вказано. Зокрема, не вказано порядок, в якому кожен аргумент fоцінюється щодо інших. i++може оцінюватися раніше i, або навпаки. Дійсно, він може оцінити другий виклик в іншому порядку, незважаючи на те, що знаходиться під тим самим компілятором.
Однак оцінку кожного аргументу потрібно виконати повністю, з усіма побічними ефектами, перед виконанням будь-якого іншого аргументу. Тож ви можете отримати f(1, 1)(другий аргумент оцінюється першим) або f(1, 2)(перший аргумент оцінюється першим). Але ви ніколи не отримаєте f(2, 2)або щось інше такого характеру.
std::cout << f() << f() << f();
було невизначеним, але воно стане сумісним з пріоритетом оператора, так що перша оцінка fбуде першою в потоці (приклади нижче).
f(g(), h(), j());
досі має невизначений порядок оцінки g, h та j. Зверніть увагу, що для getf()(g(),h(),j())правил зазначено, що getf()вони будуть оцінені раніше g, h, j.
Також зверніть увагу на наступний приклад із тексту пропозиції:
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, "");
Приклад походить із мови програмування C ++ , 4-е видання, Stroustrup, і раніше він був невизначеним, але з C ++ 17 він буде працювати, як очікувалося. Були подібні проблеми з функціями, що відновлюються ( .then( . . . )).
В якості іншого прикладу розглянемо наступне:
#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() ;
}
З C ++ 14 і раніше ми можемо (і будемо) отримувати такі результати, як
play
no,and,Work,All,
замість
All,work,and,no,play
Зауважте, що вищезазначене по суті те саме, що і
(((((std::cout << spk()) << spk()) << spk()) << spk()) << spk()) ;
Але все-таки до С ++ 17 не було жодної гарантії, що перші дзвінки прийдуть першими в потік.
Список літератури: З прийнятої пропозиції :
Вирази постфіксу обчислюються зліва направо. Це включає виклики функцій та вирази вибору членів.
Вирази призначення призначаються справа наліво. Сюди входять складні завдання.
Операнди для операторів зсуву обчислюються зліва направо. Підсумовуючи, наступні вирази обчислюються в порядку a, потім b, потім c, потім d:
- ab
- a-> b
- a -> * b
- a (b1, b2, b3)
- b @ = a
- a [b]
- a << b
- a >> b
Крім того, ми пропонуємо наступне додаткове правило: порядок обчислення виразу, що включає перевантажений оператор, визначається порядком, пов'язаним з відповідним вбудованим оператором, а не правилами викликів функцій.
Змінити примітка: Мій початковий відповідь неправильно a(b1, b2, b3). Порядок b1, b2, b3до сих пір НЕ визначено. (дякую @KABoissonneault, всі коментатори.)
Однак, (як @Yakk вказує) , і це дуже важливо: Навіть коли b1, b2, b3нетривіальні вирази, кожен з них повністю оцінені і пов'язані з відповідним параметром функції До початку бути оцінені іншими. Стандарт зазначає це так:
§ 5.2.2 - Виклик функції 5.2.2.4:
. . . Вираз postfix секвенується перед кожним виразом у списку виразів та будь-яким аргументом за замовчуванням. Кожне обчислення значення та побічний ефект, пов’язаний з ініціалізацією параметра, та сама ініціалізація послідовно розподіляються перед кожним обчисленням значення та побічним ефектом, пов’язаним з ініціалізацією будь-якого наступного параметра.
Однак одне з цих нових речень відсутнє в проекті GitHub :
Кожне обчислення значення та побічний ефект, пов’язаний з ініціалізацією параметра, та сама ініціалізація послідовно розподіляються перед кожним обчисленням значення та побічним ефектом, пов’язаним з ініціалізацією будь-якого наступного параметра.
Приклад є . Це вирішує десятилітні проблеми ( як пояснив Герб Саттер ), за винятком безпеки, де щось на зразок
f(std::unique_ptr<A> a, std::unique_ptr<B> b);
f(get_raw_a(), get_raw_a());
витік, якщо один із викликів get_raw_a()викине до того, як інший сирий вказівник буде прив'язаний до його розумного параметра вказівника.
Як зазначає TC, приклад помилковий, оскільки конструкція unique_ptr із необробленого вказівника явна, що перешкоджає компіляції. *
Також зверніть увагу на це класичне запитання (з позначкою C , а не C ++ ):
int x=0;
x++ + ++x;
ще не визначено.