Is it possible to change the temporary object and to pass it as an argument?

Question

Is it possible to change the temporary object and to pass it as an argument?

struct Foo {    
   Foo& ref() { return *this; }
   Foo& operator--() { /*do something*/; return *this; }
   // another members
};
Foo getfoo() { return Foo(); } // return Foo() for example or something else
void func_val(Foo x) {}
void func_ref(const Foo & x) {}

int main() {
   func_val(--getfoo());     // #1 OK?
   func_ref(getfoo());       // #2 OK?
   func_ref(getfoo().ref()); // #3 OK?
   // the following line is a real example 
   //    using --vector.end() instead of --getfoo()
   func_ref(--getfoo());     // #4 OK? 

   const Foo & xref = --getfoo(); //  Does const extend the lifetime ?
   func_ref(xref);     // #5 OK? 
   func_val(xref);     // #6 OK? 

}

It is known that assigning a temporary object to the const reference extends the lifetime of this temporary object. And what about #4 and #5 lines of my code? Is it true that reference x is always valid in the function func_ref? The thing is that operator-- returns some reference and the compiler does not see any relation between this reference and the temporary we created.

Answer 1

Temporaries always live for the lifetime of the full expression in which they're created anyway. Hence, in the expression statement func_val(--getfoo());, the lifetime of the temporary returned by the getfoo() expression doesn't need any extension. The statement doesn't end until after func_val() had returned.

Answer 2

func_val(--getfoo());     // #1 OK?

Yes, OK. The operator-- is a member-function, which is called, and which returns itself (and lvalue referring to itself). The object is then copied into the parameter of func_val. Notice that return value optimization is not allowed to apply, since the temporary created by getfoo() was previously bound to a reference.

func_ref(getfoo());       // #2 OK?

Yes, OK. The call getfoo() returns a temporary which is bound to the const reference. A copy constructor is required, but the call it it may be optimized out by the implementation. The temporary persists until the end of the full-expression containing the call to func_ref (the whole expression statement here).

func_ref(getfoo().ref());

Yes, OK. No copy constructor required, as we bind the const reference not to a temporary but to the lvalue representing the object itself.

// the following line is a real example 
//    using --vector.end() instead of --getfoo()

That is not required to work. Think of a situation where vector.end() returns a T* (allowed). You are not allowed to modify rvalues of non-class type, so in that case, this would be ill-formed.

func_ref(--getfoo());

Yes, OK. The argument is evaluated as in #1, but the resulting lvalue is directly passed and the const reference is bound to it. In this sense it's equal to #3 (except for the decrement side effect).

const Foo & xref = --getfoo();

The Standard wording is not entirely clear. It surely intends to only extend lifetime of objects not yet bound to a reference. But in our case, --getfoo() yields an lvalue refering to a temporary object which was previously bound to a reference. It may be worth submitting a defect report to the committee (i may also have missed wording that requires the temporary object to not be bounded to a reference yet).

In any case, the intended behavior is to destruct the temporary that results from getfoo() at the end of initializing xref, so xref will become a dangling reference.

The thing is that operator-- returns some reference and the compiler does not see any relation between this reference and the temporary we created.

Exactly (but applies only to the initialization of xref which will go mad. In all other cases, the intended behavior you want (or what i believe you want) is achieved).