Alguns casos comuns em que a ordem de avaliação não foi especificada até o momento são especificados e válidos com C++17. Algum comportamento indefinido agora não é especificado.
i = 1;
f(i++, i)
foi indefinido, mas agora não foi especificado. Especificamente, o que não é especificado é a ordem em que cada argumento para fé avaliado em relação aos outros. i++pode ser avaliado antes i, ou vice-versa. Na verdade, ele pode avaliar uma segunda chamada em uma ordem diferente, apesar de estar no mesmo compilador.
No entanto, a avaliação de cada argumento é necessária para ser executada completamente, com todos os efeitos colaterais, antes da execução de qualquer outro argumento. Portanto, você pode obter f(1, 1)(segundo argumento avaliado primeiro) ou f(1, 2)(primeiro argumento avaliado primeiro). Mas você nunca obterá f(2, 2)ou qualquer outra coisa dessa natureza.
std::cout << f() << f() << f();
não foi especificado, mas se tornará compatível com a precedência do operador, de modo que a primeira avaliação de fvenha primeiro no fluxo (exemplos abaixo).
f(g(), h(), j());
ainda tem uma ordem de avaliação não especificada de g, h e j. Observe que para getf()(g(),h(),j()), as regras indicam que getf()será avaliado antes g, h, j.
Observe também o seguinte exemplo do texto da proposta:
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, "");
O exemplo vem de The C ++ Programming Language , 4ª edição, Stroustrup, e costumava ser um comportamento não especificado, mas com C ++ 17 funcionará conforme o esperado. Ocorreram problemas semelhantes com funções retomáveis ( .then( . . . )).
Como outro exemplo, considere o seguinte:
#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() ;
}
Com C ++ 14 e antes, podemos (e iremos) obter resultados como
play
no,and,Work,All,
ao invés de
All,work,and,no,play
Observe que o acima está em vigor o mesmo que
(((((std::cout << spk()) << spk()) << spk()) << spk()) << spk()) ;
Mesmo assim, antes do C ++ 17 não havia garantia de que as primeiras chamadas viriam primeiro no fluxo.
Referências: Da proposta aceita :
As expressões Postfix são avaliadas da esquerda para a direita. Isso inclui chamadas de funções e expressões de seleção de membros.
As expressões de atribuição são avaliadas da direita para a esquerda. Isso inclui atribuições compostas.
Operandos para operadores de deslocamento são avaliados da esquerda para a direita. Em resumo, as seguintes expressões são avaliadas na ordem a, depois b, depois c e depois d:
- ab
- a-> b
- a -> * b
- a (b1, b2, b3)
- b @ = a
- a [b]
- a << b
- a >> b
Além disso, sugerimos a seguinte regra adicional: a ordem de avaliação de uma expressão envolvendo um operador sobrecarregado é determinada pela ordem associada ao operador embutido correspondente, não pelas regras para chamadas de função.
Editar nota: minha resposta original foi mal interpretada a(b1, b2, b3). A ordem de b1, b2, b3ainda é indeterminado. (obrigado @KABoissonneault, todos os comentaristas.)
No entanto, (como aponta @Yakk out) e isto é importante: Mesmo quando b1, b2, b3são expressões não-triviais, cada um deles são completamente avaliadas e amarrado ao respectivo parâmetro de função antes que os outros são começou a ser avaliada. O padrão afirma assim:
§5.2.2 - Chamada de função 5.2.2.4:
. . . A expressão postfix é sequenciada antes de cada expressão na lista de expressões e qualquer argumento padrão. Cada cálculo de valor e efeito colateral associado à inicialização de um parâmetro, e a própria inicialização, é sequenciado antes de cada cálculo de valor e efeito colateral associado à inicialização de qualquer parâmetro subsequente.
No entanto, uma dessas novas frases está faltando no rascunho do GitHub :
Cada cálculo de valor e efeito colateral associado à inicialização de um parâmetro, e a própria inicialização, é sequenciado antes de cada cálculo de valor e efeito colateral associado à inicialização de qualquer parâmetro subsequente.
O exemplo está aí. Ele resolve problemas de décadas atrás ( conforme explicado por Herb Sutter ) com segurança excepcional, onde coisas como
f(std::unique_ptr<A> a, std::unique_ptr<B> b);
f(get_raw_a(), get_raw_a());
vazaria se uma das chamadas get_raw_a()fosse lançada antes que o outro ponteiro bruto fosse vinculado ao seu parâmetro de ponteiro inteligente.
Conforme apontado por TC, o exemplo é falho, pois a construção de unique_ptr a partir do ponteiro bruto é explícita, impedindo que ele seja compilado. *
Observe também esta pergunta clássica (marcada como C , não C ++ ):
int x=0;
x++ + ++x;
ainda está indefinido.