How come a non-const reference cannot bind to a temporary object?

Question

Why is it not allowed to get non-const reference to a temporary object, which function getx() returns? Clearly, this is prohibited by C++ Standard but I am in

Answer 1

In your code getx() returns a temporary object, a so-called "rvalue". You can copy rvalues into objects (aka. variables) or bind them to to const references (which will extend their life-time until the end of the reference's life). You cannot bind rvalues to non-const references.

This was a deliberate design decision in order to prevent users from accidentally modifying an object that is going to die at the end of the expression:

g(getx()); // g() would modify an object without anyone being able to observe

If you want to do this, you will have to either make a local copy or of the object first or bind it to a const reference:

X x1 = getx();
const X& x2 = getx(); // extend lifetime of temporary to lifetime of const reference

g(x1); // fine
g(x2); // can't bind a const reference to a non-const reference

Note that the next C++ standard will include rvalue references. What you know as references is therefore becoming to be called "lvalue references". You will be allowed to bind rvalues to rvalue references and you can overload functions on "rvalue-ness":

void g(X&);   // #1, takes an ordinary (lvalue) reference
void g(X&&);  // #2, takes an rvalue reference

X x; 
g(x);      // calls #1
g(getx()); // calls #2
g(X());    // calls #2, too

The idea behind rvalue references is that, since these objects are going to die anyway, you can take advantage of that knowledge and implement what's called "move semantics", a certain kind of optimization:

class X {
  X(X&& rhs)
    : pimpl( rhs.pimpl ) // steal rhs' data...
  {
    rhs.pimpl = NULL; // ...and leave it empty, but deconstructible
  }

  data* pimpl; // you would use a smart ptr, of course
};


X x(getx()); // x will steal the rvalue's data, leaving the temporary object empty

Answer 2

The main issue is that

g(getx()); //error

is a logical error: g is modifying the result of getx() but you don't have any chance to examine the modified object. If g didn't need to modify its parameter then it wouldn't have required an lvalue reference, it could have taken the parameter by value or by const reference.

const X& x = getx(); // OK

is valid because you sometimes need to reuse the result of an expression, and it's pretty clear that you're dealing with a temporary object.

However it is not possible to make

X& x = getx(); // error

valid without making g(getx()) valid, which is what the language designers were trying to avoid in the first place.

g(getx().ref()); //OK

is valid because methods only know about the const-ness of the this, they don't know if they are called on an lvalue or on an rvalue.

As always in C++, you have a workaround for this rule but you have to signal the compiler that you know what you're doing by being explicit:

g(const_cast<x&>(getX()));

Answer 3

Seems like the original question as to why this is not allowed has been answered clearly: "because it is most likely an error".

FWIW, I thought I'd show how to it could be done, even though I don't think it's a good technique.

The reason I sometimes want to pass a temporary to a method taking a non-const reference is to intentionally throw away a value returned by-reference that the calling method doesn't care about. Something like this:

// Assuming: void Person::GetNameAndAddr(std::string &name, std::string &addr);
string name;
person.GetNameAndAddr(name, string()); // don't care about addr

As explained in previous answers, that doesn't compile. But this compiles and works correctly (with my compiler):

person.GetNameAndAddr(name,
    const_cast<string &>(static_cast<const string &>(string())));

This just shows that you can use casting to lie to the compiler. Obviously, it would be much cleaner to declare and pass an unused automatic variable:

string name;
string unused;
person.GetNameAndAddr(name, unused); // don't care about addr

This technique does introduce an unneeded local variable into the method's scope. If for some reason you want to prevent it from being used later in the method, e.g., to avoid confusion or error, you can hide it in a local block:

string name;
{
    string unused;
    person.GetNameAndAddr(name, unused); // don't care about addr
}

-- Chris

Answer 4

The evil workaround involves the 'mutable' keyword. Actually being evil is left as an exercise for the reader. Or see here: http://www.ddj.com/cpp/184403758

Answer 5

Why is discussed in the C++ FAQ (boldfacing mine):

In C++, non-const references can bind to lvalues and const references can bind to lvalues or rvalues, but there is nothing that can bind to a non-const rvalue. That's to protect people from changing the values of temporaries that are destroyed before their new value can be used. For example:

void incr(int& a) { ++a; }
int i = 0;
incr(i);    // i becomes 1
incr(0);    // error: 0 is not an lvalue

If that incr(0) were allowed either some temporary that nobody ever saw would be incremented or - far worse - the value of 0 would become 1. The latter sounds silly, but there was actually a bug like that in early Fortran compilers that set aside a memory location to hold the value 0.

Answer 6

What you are showing is that operator chaining is allowed.

 X& x = getx().ref(); // OK

The expression is 'getx().ref();' and this is executed to completion before assignment to 'x'.

Note that getx() does not return a reference but a fully formed object into the local context. The object is temporary but it is not const, thus allowing you to call other methods to compute a value or have other side effects happen.

// It would allow things like this.
getPipeline().procInstr(1).procInstr(2).procInstr(3);

// or more commonly
std::cout << getManiplator() << 5;

Look at the end of this answer for a better example of this

You can not bind a temporary to a reference because doing so will generate a reference to an object that will be destroyed at the end of the expression thus leaving you with a dangling reference (which is untidy and the standard does not like untidy).

The value returned by ref() is a valid reference but the method does not pay any attention to the lifespan of the object it is returning (because it can not have that information within its context). You have basically just done the equivalent of:

x& = const_cast<x&>(getX());

The reason it is OK to do this with a const reference to a temporary object is that the standard extends the lifespan of the temporary to the lifespan of the reference so the temporary objects lifespan is extended beyond the end of the statement.

So the only remaining question is why does the standard not want to allow reference to temporaries to extend the life of the object beyond the end of the statement?

I believe it is because doing so would make the compiler very hard to get correct for temporary objects. It was done for const references to temporaries as this has limited usage and thus forced you to make a copy of the object to do anything useful but does provide some limited functionality.

Think of this situation:

int getI() { return 5;}
int x& = getI();

x++; // Note x is an alias to a variable. What variable are you updating.

Extending the lifespan of this temporary object is going to be very confusing.
While the following:

int const& y = getI();

Will give you code that it is intuitive to use and understand.

If you want to modify the value you should be returning the value to a variable. If you are trying to avoid the cost of copying the obejct back from the function (as it seems that the object is copy constructed back (technically it is)). Then don't bother the compiler is very good at 'Return Value Optimization'