Re: Revistiing using return value as reference
On 2007-12-27 02:19, johanatan wrote:
On Dec 26, 6:33 am, Erik Wikstr?m <Erik-wikst...@telia.com> wrote:
On 2007-12-26 06:01, johanatan wrote:
On Dec 25, 3:00 pm, "Jim Langston" <tazmas...@rocketmail.com> wrote:
Foo& Bar( int Val )
{
return Foo( Val );
}
Will not work, can not convert Foo to Foo&
Should work, but not a very useful thing to do as local copy dies
immediately.
Should not work, a reference can not bind to a rvalue.
Ok, you're right. I just tried this again in Ch (a C++ interpreter)
-- apparently the method wasn't being called before and so wasn't
compiled.
Does not work, same thing, can not convert Foo to Foo&.
Should also work. Something else is going on as that syntax is
compiling fine in my compiler.
Get a new compiler. Once again, you can not bind a reference to a rvalue.
This is certainly an interesting design decision of C++. I suspect it
was a 'safety' feature built in, but I prefer languages to be more
flexible by inferring as much as possible from context. What is the
danger of binding to an r-value?
Consider the following code:
int& r = 5;
r = 6;
If I can bind a reference to a value I can also change that value. But
that is not how a reference works, a reference is a alias for an object
not an object on its own. Therefore a reference can not bind to a rvalue.
A value is a value (and if you were thinking in purely functional
terms, this is just a transformation that happens in one line instead
of two).
But C++ is not a functional language, thinking in functional terms will
lead you astray.
Does it really help things to declare the Foo on one line return it
instead of the constructor call? Substitution (i.e., rewriting) is
the name of the game. Why prevent this level of compaction?
Because when you declare the object first and then returns it you have
an lvalue, which you can bind a reference to.
--
Erik Wikstr?m