GCC bug? Chaining methods, broken sequence point

Question

I've been debugging a program for some time, and eventually found the error was due to a reference not being updated as I thought it would be.

Here's a example that shows the problem I encountered:

#include <iostream>
using namespace std;

struct Test {
    Test& set(int& i){ i = 10; return *this; }
    Test& print(const int& i){ cout << i << endl; return *this; }
};

int main(void){
    int i = 0;
    Test t;

    t.set(i).print(i + 5);

    return 0;
}

I had expected that the print() method here would output 15, but instead it outputs 5.

EDIT: 10 days later I just realised that with clang it outputs 15! Is this a bug in GCC?

Answer 1

Let me try interpreting the C++11 standard on this. In §1.9/15 it says:

Except where noted, evaluations of operands of individual operators and of subexpressions of individual expressions are unsequenced. [...] 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, the behavior is undefined.

Certainly int is an scalar type, and t.set(i).print(i + 5); contains a side effect on i in set() and the value computation i + 5, so if not noted otherwise, the behavior is indeed undefined. Reading §5.2.5 ("Class member access"), I could not find any notes about sequences regarding the . operator. [But see edit below!]

Note, however that it is of course guaranteed that set() is executed before print() because the latter receives the return value of the former as an (implicit this) argument. The culprit here is that the value computation for print's arguments is unsequenced indeterminately sequenced relative to the call of set.

EDIT: After reading the answer in your (@Xeno's) comment, I reread the paragraph in the standard, and in fact it later says:

Every evaluation in the calling function (including other function calls) that is not otherwise specifically sequenced before or after the execution of the body of the called function is indeterminately sequenced with respect to the execution of the called function.

Because indeterminately sequenced is not unsequenced ("execution of unsequenced evaluations can overlap", §1.9/13), this is indeed not undefined behavior, but "just" unspecified behavior, meaning that both 15 and 5 are correct outputs.

So when < means "sequenced before" and ~ means "indeterminately sequenced", we have:

(value computations for print()'s arguments ~ execution of set()) < execution of print()

Answer 2

There's no guarantee in C++ about the order in which function arguments in a single expression are evaluated, not even when these functions are chained method calls. You are invoking undefined behavior here and that's what you get.

The . operator does imply sequencing, but only insofar that the expression before the . has to be fully evaluated before the member is accessed. It doesn't mean that the evaluations of subexpressions are suspended until that point.

Also, don't pass ints by const int&, there's no way this could be faster than passing an int directly (unless for some strange reason int doesn't fit into a processor word and the reference does).

Answer 3

[too long for a comment:]

If adding

Test& add(int& i, const int toadd)
{
  i += toadd;
  return *this;
}

This call

t.set(i).add(i, 5).print(i);

returns

15

From this I conclude that the culprit is the i + 5 as parameter to print.