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?

Why write such code that both looks ugly and will always likely to be subject to errors? Why the requirement to chain methods? — Ed Heal
@EdHeal I have a class with many methods that each do very little, and need to call a lot of them in a row. I chose to allow chaining like this to save quite a bit of typing. Now that I have found this behaviour I'll consider removing the chaining. — Xeno
You pass 0 + 5 to print() and than print it directly. Debug your code next time. — StoryTeller - Unslander Monica
@StoryTeller Then why do g++ and clang++ differ in their outputs? — Xeno

Oberon Oberon · Accepted Answer · 2014-02-16T13:09:36

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()

GCC bug? Chaining methods, broken sequence point

3 Answers