Re: Revistiing using return value as reference
On 2007-12-27 20:47, johanatan wrote:
On Dec 27, 6:49 am, Erik Wikstr?m <Erik-wikst...@telia.com> wrote:
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.
Ok, so I suspect it was decided early on that the easiest way to
prevent 'changing' a reference was to disallow setting it to *any* r-
value?
You can never change a reference, only the object it refers to.
That surely simplifies writing a compiler for the language,
but seems like a pretty arbitrary restriction to place on programmers
(and it seems possible to me to make a compiler that could
differentiate between an initial setting and subsequent 'changes').
I think it makes sense, you can not create a reference to an object that
can no be changed. Call it a safety mechanism that prevents users from
making stupid mistakes.
Of course that does not prevent one from referring to r-values, but you
need to have a const reference (to ensure that the user does not modify
the rvalue through the reference).
And, another question that follows naturally-- 'Why aren't references
allowed to be changed to begin with?' If they were, then the r-value
problem goes away and then the integration of boost's 'shared_ptr'
functionality would be much more seamless at this time.
If you could change a reference then you would have a pointer, and we
already have those. And as we all know pointers are not very safe to
play with. Not sure what you mean with shared_ptr would be more seam-
lessly integrated, though.
I really would have preferred some sort of new syntax to the language
itself instead of tacking on another lib as part of the 'standard'.
For instance, you could use:
int^ x;
to represent a 'smart' ptr in the same way that 'int&' is a reference.
Personally I prefer to keep the stuff in the language to a minimum and
have a library which provides the stuff I need, but that is just me. If
you want a language where everything (well, at least a lot) is hidden
from the programmer with syntactic sugar try C#.
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.
Well, when you write:
int x = g(f(y));
you're doing 'functional' stuff (aside from the storage in a
variable).
In a functional language the above would likely mean that g() was a
function taking a function which takes one argument as argument, while
in C++ it means that g() is called with the value returned from f(x).
My point was that the practice of programming boils down
to 'rewrites', or substitutions or transformations. Even when in an
imperative language, much of the job is about writing one thing to
represent another (i.e., symbols).
Yes, programming is all about collecting information and then
transforming it into something else.
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.
Yea, but, once again, that's only because of the (as far as I can
tell) arbitrary decision to disallow setting to r-value. I think
there's a misunderstanding here between what is 'required' by the
syntax of the language and the requirements imposed upon the language
by external forces (at least in my mind).
I think that Andrew Koenig's example makes it quite clear why you can
not bind a reference to an r-value, in many cases it simply does not
make sense. I have two questions for you:
1. Are you aware of and understand the difference between a reference
and a const reference?
2. Can you give an example of when it would be useful to bind a
reference to a r-value?
--
Erik Wikstr?m