Некоторые общие случаи, когда порядок оценки до сих пор не определен , указаны и действительны с 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, "");
Пример взят из The C ++ Programming Language , 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()) ;
Но все же до C ++ 17 не было гарантии, что первые вызовы попадут в поток первыми.
Ссылки: Из принятого предложения :
Выражения Postfix оцениваются слева направо. Сюда входят вызовы функций и выражения выбора членов.
Выражения присваивания оцениваются справа налево. Сюда входят составные задания.
Операнды для операторов сдвига оцениваются слева направо. Таким образом, следующие выражения вычисляются в порядке a, затем b, затем c, затем d:
- ab
- а-> б
- а -> * б
- а (b1, b2, b3)
- б @ = а
- а [б]
- а << б
- а >> б
Кроме того, мы предлагаем следующее дополнительное правило: порядок вычисления выражения, включающего перегруженный оператор, определяется порядком, связанным с соответствующим встроенным оператором, а не правилами для вызовов функций.
Изменить примечание: мой первоначальный ответ неверно истолкован a(b1, b2, b3). Порядок b1, b2, b3до сих пор не определен. (спасибо @KABoissonneault, всем комментаторам.)
Однако, (как @Yakk указывает) , и это очень важно: Даже когда b1, b2, b3нетривиальные выражения, каждый из них полностью оценены и связаны с соответствующим параметром функции До начала быть оценены другими. Стандарт гласит это так:
§5.2.2 - Вызов функции 5.2.2.4:
. . . Постфиксное-выражение упорядочивается перед каждым выражением в списке-выражении и любым аргументом по умолчанию. Каждое вычисление значения и побочный эффект, связанный с инициализацией параметра, а также сама инициализация, упорядочиваются перед каждым вычислением значения и побочным эффектом, связанным с инициализацией любого последующего параметра.
Однако одно из этих новых предложений отсутствует в черновике 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;
все еще не определено.