C++ execution order in method chaining

C++ Problem Overview

The output of this program:

#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);
}

Is:

method 1
method 2:0

Why is nu not 1 when meth2() starts?

C++ Solutions

Solution 1 - C++

Because evaluation order is unspecified.

You are seeing nu in main being evaluated to 0 before even meth1 is called. This is the problem with chaining. I advise not doing it.

Just make a nice, simple, clear, easy-to-read, easy-to-understand program:

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

Solution 2 - C++

I think this part of the draft standard regarding order of evaluation is relevant:

> 1.9 Program Execution > > ... > > 15. Except where noted, evaluations of operands of individual operators and of subexpressions of individual expressions are unsequenced. The value computations of the operands of an operator are sequenced before the value computation of the result of the operator. If a side effect on a scalar object is unsequenced relative to either another side effect on the same scalar object or a value computation using the value of the same scalar object, and they are not potentially concurrent, the behavior is undefined

and also:

> 5.2.2 Function call > > ... > > 8. [ Note: The evaluations of the postfix expression and of the arguments are all unsequenced relative to one another. All side effects of argument evaluations are sequenced before the function is entered — end note ]

So for your line c.meth1(&nu).meth2(nu);, consider what is happening in operator in terms of the function call operator for the final call to meth2, so we clearly see the breakdown into the postfix expression and argument nu:

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

The evaluations of the postfix expression and argument for the final function call (i.e. the postfix expression c.meth1(&nu).meth2 and nu) are unsequenced relative to one another as per the function call rule above. Therefore, the side-effect of the computation of the postfix expression on the scalar object ar is unsequenced relative to the argument evaluation of nu prior to the meth2 function call. By the program execution rule above, this is undefined behaviour.

In other words, there is no requirement for the compiler to evaluate the nu argument to the meth2 call after the meth1 call - it is free to assume no side-effects of meth1 affect the nu evaluation.

The assembly code produced by the above contains the following sequence in the main function:

Variable nu is allocated on the stack and initialised with 0.
A register (ebx in my case) receives a copy of the value of nu
The addresses of nu and c are loaded into parameter registers
meth1 is called
The return value register and the previously cached value of nu in the ebx register are loaded into parameter registers
meth2 is called

Critically, in step 5 above the compiler allows the cached value of nu from step 2 to be re-used in the function call to meth2. Here it disregards the possibility that nu may have been changed by the call to meth1 - 'undefined behaviour' in action.

NOTE: This answer has changed in substance from its original form. My initial explanation in terms of side-effects of operand computation not being sequenced before the final function call were incorrect, because they are. The problem is the fact that computation of the operands themselves is indeterminately sequenced.

Solution 3 - C++

In the 1998 C++ standard, Section 5, para 4

> Except where noted, the order of evaluation of operands of individual operators and subexpressions of individual expressions, and the order in which side effects take place, is unspecified. Between the previous and next sequence point a scalar object shall have its stored value modified at most once by the evaluation of an expression. Furthermore, the prior value shall be accessed only to determine the value to be stored. The requirements of this paragraph shall be met for each allowable ordering of the subexpressions of a full expression; otherwise the behavior is undefined.

(I've omitted a reference to footnote #53 which is not relevant to this question).

Essentially, &nu must be evaluated before calling c1::meth1(), and nu must be evaluated before calling c1::meth2(). There is, however, no requirement that nu be evaluated before &nu (e.g. it is permitted that nu be evaluated first, then &nu, and then c1::meth1() is called - which might be what your compiler is doing). The expression *ar = 1 in c1::meth1() is therefore not guaranteed to be evaluated before nu in main() is evaluated, in order to be passed to c1::meth2().

Later C++ standards (which I don't currently have on the PC I'm using tonight) have essentially the same clause.

Solution 4 - C++

I think when compiling ,before the funtions meth1 and meth2 are really called, the paramaters have been passed to them. I mean when you use "c.meth1(&nu).meth2(nu);" the value nu = 0 have been passed to meth2, so it doesn't matter wether "nu" is changed latter.

you can try this:

#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();
}

it will get the answer you want

Solution 5 - C++

The answer to this question depends on the C++ standard.

The rules have changed since C++17 with P0145 accepted into the spec. Since C++17 the order of evaluation is defined and parameter evaluation would be performed according to the order of the function calls. Note that parameter evaluation order inside a single function call is still not specified.

So order of evaluation in chaining expressions is guaranteed, since C++17, to work in the actual order of the chain: the code in question is guaranteed since C++17 to print:

method 1
method 2:1

Before C++17 it could print the above, but could also print:

method 1
method 2:0

Content Type	Original Author	Original Content on Stackoverflow
Question	Moises Viñas	View Question on Stackoverflow
Solution 1 - C++	Lightness Races in Orbit	View Answer on Stackoverflow
Solution 2 - C++	Smeeheey	View Answer on Stackoverflow
Solution 3 - C++	Peter	View Answer on Stackoverflow
Solution 4 - C++	T-shirt saintor	View Answer on Stackoverflow
Solution 5 - C++	Amir Kirsh	View Answer on Stackoverflow