¿Cuáles son las garantías de orden de evaluación introducidas por C++ 17?

Algunos casos comunes en los que el orden de evaluación no se ha especificado hasta el momento , 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 se evalúa cada argumento fen 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, es necesario que la evaluación de cada argumento se ejecute por completo, con todos los efectos secundarios, antes de la ejecución de cualquier otro argumento. Por lo tanto, podría obtener f(1, 1)(el segundo argumento se evalúa primero) o f(1, 2)(el primer argumento se evalúa primero). Pero nunca obtendrás f(2, 2)nada de esa naturaleza.

std::cout << f() << f() << f();

no se especificó, pero será compatible con la precedencia de operadores para que la primera evaluación de fsea 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.

Tenga en cuenta también 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 del lenguaje de programación C++ , cuarta edición, Stroustrup, y solía tener 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;
        // Pre-C++17 version:
        auto word = words[i] + (i+1==words.size()?"\n":",");
        ++i;
        return word;
        // Still not possible with C++17:
        // return words[i++] + (i==words.size()?"\n":",");

    }
};

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 lugar 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 Postfix 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 desplazar 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:

1. ab
2. a->b
3. a->*b
4. a(b1, b2, b3)
5. b@=a
6. un[b]
7. a << b
8. 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 operador incorporado correspondiente, no por las reglas para las llamadas a funciones.

Nota de edición: mi respuesta original se malinterpretó a(b1, b2, b3). El orden de b1, b2, b3aún no se ha especificado. (gracias @KABoissonneault, todos los comentaristas).

Sin embargo, (como señala @Yakk) y esto es importante: incluso cuando b1, b2, b3son expresiones no triviales, cada una de ellas se evalúa completamente y se vincula al parámetro de función respectivo antes de que las demás comiencen a evaluarse. La norma lo establece así:

§5.2.2 - Llamada de función 5.2.2.4:

. . . La expresión postfix se secuencia antes de cada expresión en la lista de expresiones y de cualquier argumento predeterminado. Cada cálculo de valor y efecto secundario asociado con la inicialización de un parámetro, y la inicialización misma, se secuencian 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 frases 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 misma, se secuencian 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 décadas ( como lo explica Herb Sutter ) con una seguridad excepcional 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 realizara antes de que el otro puntero sin formato estuviera vinculado a su parámetro de puntero inteligente.

Como señaló TC, el ejemplo es defectuoso ya que la construcción Unique_ptr a partir del puntero sin formato es explícita, lo que impide la compilación.*

También tenga en cuenta esta pregunta clásica (etiquetada como C , no como C++ ):

int x=0;
x++ + ++x;

aún no está definido.

Jul 21 '2016 10:07 Johan Lundberg