Algunos casos comunes en los que el orden de evaluación no se ha especificado hasta ahora se especifican y son válidos con C++17. Algunos comportamientos indefinidos ahora no están especificados.
i = 1;
f(i++, i)
no estaba definido, pero ahora no está especificado. Específicamente, lo que no se especifica es el orden en el que fse evalúa cada argumento en relación con los demás. i++podría evaluarse antes i, o viceversa. De hecho, podría evaluar una segunda llamada en un orden diferente, a pesar de estar bajo el mismo compilador.
Sin embargo, la evaluación de cada argumento debe ejecutarse completamente, con todos los efectos secundarios, antes de la ejecución de cualquier otro argumento. Por lo tanto, puede obtener f(1, 1)(segundo argumento evaluado primero) o f(1, 2)(primer argumento evaluado primero). Pero nunca obtendrá f(2, 2)ni nada de esa naturaleza.
std::cout << f() << f() << f();
no se especificó, pero será compatible con la precedencia del operador, de modo que la primera evaluación de fserá la primera en la secuencia (ejemplos a continuación).
f(g(), h(), j());
todavía tiene un orden de evaluación no especificado de g, h y j. Tenga en cuenta que para getf()(g(),h(),j()), las reglas establecen que getf()se evaluará antes g, h, j.
También tenga en cuenta el siguiente ejemplo del texto de la propuesta:
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, "");
El ejemplo proviene de The C ++ Programming Language , 4th edition, Stroustrup, y solía ser un comportamiento no especificado, pero con C ++ 17 funcionará como se esperaba. Hubo problemas similares con las funciones reanudables (.then( . . . ) ).
Como otro ejemplo, considere lo siguiente:
#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() ;
}
Con C ++ 14 y antes, podemos (y obtendremos) resultados como
play
no,and,Work,All,
en vez de
All,work,and,no,play
Tenga en cuenta que lo anterior es en efecto lo mismo que
(((((std::cout << spk()) << spk()) << spk()) << spk()) << spk()) ;
Pero aún así, antes de C ++ 17 no había garantía de que las primeras llamadas llegaran primero a la secuencia.
Referencias: De la propuesta aceptada :
Las expresiones de sufijo se evalúan de izquierda a derecha. Esto incluye llamadas a funciones y expresiones de selección de miembros.
Las expresiones de asignación se evalúan de derecha a izquierda. Esto incluye asignaciones compuestas.
Los operandos para cambiar a los operadores se evalúan de izquierda a derecha. En resumen, las siguientes expresiones se evalúan en el orden a, luego b, luego c, luego d:
- ab
- a-> b
- a -> * b
- a (b1, b2, b3)
- b @ = a
- a [b]
- a << b
- a >> b
Además, sugerimos la siguiente regla adicional: el orden de evaluación de una expresión que involucra un operador sobrecargado está determinado por el orden asociado con el correspondiente operador incorporado, no las reglas para las llamadas a funciones.
Editar nota: Mi respuesta original fue malinterpretada a(b1, b2, b3). El orden de b1, b2, b3es todavía indeterminado. (gracias @KABoissonneault, todos los comentaristas).
Sin embargo, (como se señala @Yakk) y esto es importante: Incluso cuando b1, b2, b3son expresiones no triviales, cada uno de ellos están completamente evaluados y conectado con los parámetros de la función respectiva antes de que se comenzaron a ser evaluado los otros. El estándar establece esto así:
§5.2.2 - Llamada de función 5.2.2.4:
. . . La expresión-sufijo se secuencia antes de cada expresión en la lista de expresiones y cualquier argumento predeterminado. Cada cálculo de valor y efecto secundario asociado con la inicialización de un parámetro, y la inicialización en sí, se secuencia antes de cada cálculo de valor y efecto secundario asociado con la inicialización de cualquier parámetro posterior.
Sin embargo, falta una de estas nuevas oraciones en el borrador de GitHub :
Cada cálculo de valor y efecto secundario asociado con la inicialización de un parámetro, y la inicialización en sí, se secuencia antes de cada cálculo de valor y efecto secundario asociado con la inicialización de cualquier parámetro posterior.
El ejemplo está ahí. Resuelve problemas de hace décadas ( como lo explicó Herb Sutter ) con una excepción de seguridad donde cosas como
f(std::unique_ptr<A> a, std::unique_ptr<B> b);
f(get_raw_a(), get_raw_a());
se filtraría si una de las llamadas get_raw_a()se lanzara antes de que el otro puntero sin formato estuviera vinculado a su parámetro de puntero inteligente.
Como lo señaló TC, el ejemplo es defectuoso ya que la construcción de unique_ptr a partir del puntero sin formato es explícita, lo que evita que se compile. *
También tenga en cuenta esta pregunta clásica (etiquetada C , no C ++ ):
int x=0;
x++ + ++x;
aún no está definido.