On Aug 10, 2:26 pm, Scott Meyers <NeverR...@aristeia.com> wrote:
> Given
>
>  int&& val = 0;
>  val = 42;
>
> it's my impression that (draft) C++0x specifies that the resulting
> behavior is well defined:  the temporary referred to by val is given
> the value 42.  (8.5.3/5 (last bullet) says that val refers to a
> (non-const) temporary initialized with 0, and 5.17/6 says that the
> assignment modifies the temporary.)
>
> Is my understanding correct?

Note that in the expression:

  val = 42

"val" is an lvalue.  You can take its address.  You can assign 42 to
it.

> I ask, because this is the kind of thing
> that led to the prohibition of binding rvalues to
> references-to-non-consts around 1992. Of course, back in those
> primitive times, we didn't have both lvalue references and rvalue
> references, so the situation isn't the same, but nevertheless, when a
> client asked me about this code this past week, it did give me a sense
> of deja vu all over again.

Are we having fun yet? :-)

-Howard


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Aug 10, 11:26 am, Scott Meyers <NeverR...@aristeia.com> wrote:
> Given
>
>  int&& val = 0;
>  val = 42;
>
> it's my impression that (draft) C++0x specifies that the resulting
> behavior is well defined:  the temporary referred to by val is given
> the value 42.  (8.5.3/5 (last bullet) says that val refers to a
> (non-const) temporary initialized with 0, and 5.17/6 says that the
> assignment modifies the temporary.)
>
> Is my understanding correct?  I ask, because this is the kind of thing
> that led to the prohibition of binding rvalues to
> references-to-non-consts around 1992. Of course, back in those
> primitive times, we didn't have both lvalue references and rvalue
> references, so the situation isn't the same, but nevertheless, when a
> client asked me about this code this past week, it did give me a sense
> of deja vu all over again.

This is no definite answer, but I was always under the impression that
the point of prohibiting the binding of rvalues to references wasn't
to prevent code like this:
int &r = 41;
r = 42;
because this has an actual, proper effect. The point was to prevent
code like this:
void f(int &);
f(42); // f's modifications aren't going to be visible!

Since rvalue references are basically an optimization when passing
objects that we don't care about anymore, it doesn't matter that the
modifications aren't going to be visible.

Or put it another way: non-const lvalue references are for out- or in-
out-arguments, so passing a temporary for them has a good chance of
being a mistake. Const lvalue references and rvalue references are for
in-arguments, so passing a temporary is expected.

Sebastian


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Scott Meyers" <NeverRead@aristeia.com>
>
> Given
>
> int&& val = 0;
> val = 42;
>
> it's my impression that (draft) C++0x specifies that the resulting
> behavior is well defined:  the temporary referred to by val is given
> the value 42.  (8.5.3/5 (last bullet) says that val refers to a
> (non-const) temporary initialized with 0, and 5.17/6 says that the
> assignment modifies the temporary.)
>
> Is my understanding correct?

Hopefully ;-)

> I ask, because this is the kind of thing
> that led to the prohibition of binding rvalues to
> references-to-non-consts around 1992.

Az I recall the era, that prohibition was not welcome by everyone, and
many compilers ignored it either completely or just giving low level
warning. (Okay, some treated const as lightly, but anyway...)

> Of course, back in those
> primitive times, we didn't have both lvalue references and rvalue
> references, so the situation isn't the same, but nevertheless, when a
> client asked me about this code this past week, it did give me a sense
> of deja vu all over again.

The rationale IIRC was that too many people would be surprized
realizing that some temporary soaked up the changes and disappeared.
I personally did use temporaries for caclulations and was happy. And
can't recall anyone frightened by the risk stated.   Also the current
situatiuion lacks symmetry, you can call member functions on class
rvalues at will.  And can temp.swap(var) but not var.swap(temp).  Not
nice.

I recall some SM advices to retuen const string from functions instead
of string to cover the same set of problems. Never liked that advice,
did not follow it, did not see it followed, and NO problems related to
hat are in my attention whatsoever.

With rvalue refs the picture (if I understand the feature correctly)
is somewhat different.  Those refs serve the very purpose to allow
mutatinf the temporary, stealing away the guts, etc.   The old rule
with lvalues will certainly stay, and those picking up usage of &&
will do it purposefully. And we will need less tricks to reach the
goals.

Sure the set of advices shall be updatedso both the old and new
population be aware of what is going on really, but I trust we have
good mentors up to that task ;-))  And the new rules seem to be easier
to explain, especially in a use-case oriented way.



--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Balog Pal wrote:

> I recall some SM advices to retuen const string from functions instead
> of string to cover the same set of problems. Never liked that advice,
> did not follow it, did not see it followed, and NO problems related to
> hat are in my attention whatsoever.
>

And this SM no longer offers that advice, because returning const rvalues
disables move semantics for the temporaries thus generated.

Scott

--
* C++ and Beyond: Meyers, Sutter, & Alexandrescu, Oct. 24-27 near Seattle (
http://cppandbeyond.com/)
* License my training materials for commercial (http://tinyurl.com/yfzvkp9)
or personal use (http://tinyurl.com/yl5ka5p).

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Given

 int&& val = 0;
 val = 42;

it's my impression that (draft) C++0x specifies that the resulting
behavior is well defined:  the temporary referred to by val is given
the value 42.  (8.5.3/5 (last bullet) says that val refers to a
(non-const) temporary initialized with 0, and 5.17/6 says that the
assignment modifies the temporary.)

Is my understanding correct?  I ask, because this is the kind of thing
that led to the prohibition of binding rvalues to
references-to-non-consts around 1992. Of course, back in those
primitive times, we didn't have both lvalue references and rvalue
references, so the situation isn't the same, but nevertheless, when a
client asked me about this code this past week, it did give me a sense
of deja vu all over again.

Scott

--
* C++ and Beyond: Meyers, Sutter, & Alexandrescu, Oct. 24-27 near
Seattle (http://cppandbeyond.com/)
* License my training materials for commercial
(http://tinyurl.com/yfzvkp9) or personal use
(http://tinyurl.com/yl5ka5p).

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]