Re: A non-const reference may only be bound to an lvalue?

From:

"Doug Harrison [MVP]" <dsh@mvps.org>

Newsgroups:

microsoft.public.vc.language

Date:

Fri, 14 Dec 2007 11:40:43 -0600

Message-ID:

<ndf5m31cbdqrtb4s30aoevofqas0on55q4@4ax.com>

On Fri, 14 Dec 2007 08:56:53 -0500, "Igor Tandetnik" <itandetnik@mvps.org>
wrote:

To avoid surprises like this:

void f(long& x) { x = 1; }

int y = 0;
f(y); // hypothetical, doesn't compile
assert(y == 1); // fails

If f(y) were allowed to compile, it would generate a temporary of type
long, and the function would modify that temporary, leaving the original
int variable unchanged.

It would also mean that a seemingly benign change in function
signature( from f(int&) to f(long&) ) may silently alter the behavior of
the program. As things stand now, such a change would lead to compiler
errors - much better than silent behavior change.

The thing is, that's got little to do with the typical desired usage, which
is to permit:

void f(X&);

void g()
{
   f(X());
}

There are legitimate reasons to want to do that, but I've come to accept it
shouldn't be allowed for this reason. Suppose you have a class:

struct Y
{
   // Lifetime of x must exceed object's use of it
   explicit Y(X& x)
   : m_x(x)
   {
   }

   X& m_x;
};

Whether or not you agree with the design of the class, under the existing
rule, you can't get into trouble binding a temporary to m_x, at least not
easily. And when you really need to say f(X()), there's always lvalue_cast.

--
Doug Harrison
Visual C++ MVP