Orden de ejecución de C ++ en el encadenamiento de métodos

El resultado de este programa:

#include <iostream> 
class c1
{   
  public:
    c1& meth1(int* ar) {
      std::cout << "method 1" << std::endl;
      *ar = 1;
      return *this;
    }
    void meth2(int ar)
    {
      std::cout << "method 2:"<< ar << std::endl;
    }
};

int main()
{
  c1 c;
  int nu = 0;
  c.meth1(&nu).meth2(nu);
}

Es:

method 1
method 2:0

¿Por qué nuno es 1 cuando meth2()comienza?

Porque el orden de evaluación no está especificado.

Estás viendo nuen mainser evaluado 0antes incluso de meth1ser llamado. Este es el problema del encadenamiento. Aconsejo no hacerlo.

Simplemente cree un programa agradable, simple, claro, fácil de leer y de entender:

int main()
{
  c1 c;
  int nu = 0;
  c.meth1(&nu);
  c.meth2(nu);
}

Creo que esta parte del borrador del estándar con respecto al orden de evaluación es relevante:

1.9 Ejecución del programa

...

15. Excepto donde se indique, las evaluaciones de operandos de operadores individuales y de subexpresiones de expresiones individuales no están secuenciadas. Los cálculos de valor de los operandos de un operador se secuencian antes del cálculo de valor del resultado del operador. Si un efecto secundario en un objeto escalar no está secuenciado en relación con otro efecto secundario en el mismo objeto escalar o un cálculo de valor utilizando el valor del mismo objeto escalar, y no son potencialmente concurrentes, el comportamiento no está definido

y también:

5.2.2 Llamada a función

...

8. [Nota: Las evaluaciones de la expresión de sufijo y de los argumentos no están secuenciadas entre sí. Todos los efectos secundarios de las evaluaciones de argumentos se secuencian antes de ingresar la función - nota final]

Entonces, para su línea c.meth1(&nu).meth2(nu);, considere lo que está sucediendo en el operador en términos del operador de llamada de función para la llamada final a meth2, de modo que veamos claramente el desglose en la expresión y el argumento de sufijo nu:

operator()(c.meth1(&nu).meth2, nu);

Las evaluaciones de la expresión de sufijo y el argumento para la llamada de función final (es decir, la expresión de sufijo c.meth1(&nu).meth2y nu) no están secuenciadas entre sí según la regla de llamada de función anterior. Por lo tanto, el efecto secundario del cálculo de la expresión de sufijo en el objeto escalar no arestá secuenciado en relación con la evaluación del argumento nuantes de la meth2llamada a la función. Según la regla de ejecución del programa anterior, este es un comportamiento indefinido.

En otras palabras, no es necesario que el compilador evalúe el nuargumento de la meth2llamada después de la meth1llamada; es libre de asumir que no hay efectos secundarios que meth1afecten la nuevaluación.

El código ensamblador producido por lo anterior contiene la siguiente secuencia en la mainfunción:

1. La variable nuse asigna en la pila y se inicializa con 0.
2. Un registro ( ebxen mi caso) recibe una copia del valor denu
3. Las direcciones de nuy cse cargan en registros de parámetros
4. meth1 se llama
5. El registro del valor de retorno y el valor previamente almacenado en caché de nuen el ebxregistro se cargan en los registros de parámetros
6. meth2 se llama

Críticamente, en el paso 5 anterior, el compilador permite que el valor en caché nudel paso 2 se reutilice en la llamada de función a meth2. Aquí se ignora la posibilidad de que nupueda haber sido cambiado por la llamada a meth1- 'comportamiento indefinido' en acción.

NOTA: Esta respuesta ha cambiado sustancialmente desde su forma original. Mi explicación inicial en términos de los efectos secundarios del cálculo de operandos que no se secuenciaron antes de la llamada final a la función fue incorrecta, porque lo son. El problema es el hecho de que el cálculo de los propios operandos tiene una secuencia indeterminada.

En el estándar C ++ de 1998, Sección 5, párrafo 4

Excepto donde se indique, el orden de evaluación de los operandos de operadores individuales y subexpresiones de expresiones individuales, y el orden en el que se producen los efectos secundarios, no se especifica. Entre el punto de secuencia anterior y siguiente, un objeto escalar tendrá su valor almacenado modificado como máximo una vez mediante la evaluación de una expresión. Además, solo se accederá al valor anterior para determinar el valor que se almacenará. Los requisitos de este párrafo deberán cumplirse para cada ordenamiento permitido de las subexpresiones de una expresión completa; de lo contrario, el comportamiento no está definido.

(He omitido una referencia a la nota al pie # 53 que no es relevante para esta pregunta).

Esencialmente, &nudebe evaluarse antes de llamar c1::meth1()y nudebe evaluarse antes de llamar c1::meth2(). Sin embargo, no hay ningún requisito que nudeba evaluarse antes &nu(por ejemplo, se permite que nuse evalúe primero, luego &nu, y luego c1::meth1()se llame, que podría ser lo que está haciendo su compilador). Por lo tanto, no se garantiza que la expresión *ar = 1in c1::meth1()se evalúe antes nude que main()se evalúe in para poder pasarla a c1::meth2().

Los estándares posteriores de C ++ (que actualmente no tengo en la PC que estoy usando esta noche) tienen esencialmente la misma cláusula.

Creo que al compilar, antes de que las funciones meth1 y meth2 se llamen realmente, se les han pasado los parámetros. Me refiero a cuando usa "c.meth1 (& nu) .meth2 (nu);" el valor nu = 0 se ha pasado a meth2, por lo que no importa si "nu" se cambia más tarde.

puedes probar esto:

#include <iostream> 
class c1
{
public:
    c1& meth1(int* ar) {
        std::cout << "method 1" << std::endl;
        *ar = 1;
        return *this;
    }
    void meth2(int* ar)
    {
        std::cout << "method 2:" << *ar << std::endl;
    }
};

int main()
{
    c1 c;
    int nu = 0;
    c.meth1(&nu).meth2(&nu);
    getchar();
}

obtendrá la respuesta que desea