be binded to a rvalue (return of X(), which is a temporary object, i.e.
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