Re: Shooting yourself in the foot with rvalue references Organization: Arcor
"SG" <s.gesemann@gmail.com> schrieb im Newsbeitrag news:e00bdb02-c58b-4fc3-b2cc-6f6a730f55c2@j28g2000vbp.googlegroups.com...
On 15 Mai, 03:40, Matthias Hofmann wrote:
What security hole? It used to have one. But that got closed (and now
the initialization of rvalue references has been restricted to rvalues
and things convertible into temporary objects of appropriate types).
So, basically, an rvalue reference can only refer to something that
may be modified without anybody caring about it. Once you have a named
rvalue reference, you have the chance of referring to the object
multiple times. This is a characteristic of lvalues. So, for security
reasons, a named rvalue reference is an lvalue expression (so that no
accidental modification/movement can happen).
I remember that string literals are usually kept in a read-only section of
the program executable, so that modifying them is undefined behaviour. I
thought that integer literals would be handled in a similar way, but I just
realized that creating a temporary int is much easier for the compiler than
creating a temporary character array. I thought that modifying an integer
literal through an rvalue reference was undefined behaviour for the same
reason that modifying string literals is, but as I have learned from your
replies and through some research on the internet, I was in error.
Basically, as a beginner, you have to keep the following three things
in mind:
(1) As a rule of thumb: If you feel the need to write a function which
returns an rvalue reference, it is _probably_ the wrong thing to do.
Rvalue references are references. Returning references to function-
local objects is still wrong, no matter what kind of reference it is.
Special exceptions: std::move, std::forward.
If you have a function that returns an object by value, you have an rvalue
already. The only case that I can imagine where it could make sense to have
an rvalue reference as a function's return type is something like this:
std::string GetString()
{ return "Hello!"; }
std::string&& GetStringIndirect()
{ return GetString(); }
But on the other hand, this probably prevents return value optimization.
Also, if GetStringIndirect() returned by value rather than by reference, the
effect would be the same, although maybe one more move construction would
take place. But what about the lifetime of the temporary returned from
GetString()? Does it live as long as the reference it is bound to?
(2) Keep in mind that the pattern T&& where T is a function template's
deducible type parameter is a special "catch everything"-pattern. It
will catch lvalues as well. Not because an rvalue references binds to
an lvalue but because of a special template argument deduction rule
and because of reference collapsing. Keep in mind that T will be
deduced to be an lvalue reference in case you use an lvalue expression
as function argument. In that case T&& will also be an lvalue
reference (due to reference collapsing).
This is about perfect forwarding. It first seemed rather complicated, but I
think I understood it after having read this:
http://thbecker.net/articles/rvalue_references/section_07.html
http://thbecker.net/articles/rvalue_references/section_08.html
Actually it's not too difficult, you only have to remember to use the "catch
everything" pattern T&& when you declare the functions parameters and call
std::forward<T>() on a parameter when you forward it.
(3) If you're not sure how to use rvalue references, don't bother or
limit yourself to writing move constructors and move assignment
operators for your custom types.
This requires some understanding of rvalue references, especially about the
pitfalls like named rvalues being lvalues. Otherwise somebody might write a
moving constructor like this:
struct X
{
X( X&& rhs ) {}
};
struct Y
{
// rhs is an lvalue!
Y( Y&& rhs ) : X( rhs ) {}
};
I forgot what C++0x says about compiler generated copy constructors when
there is a user defined move constructor, but Y's move constructor should
look like this:
// std::move() converts rhs to an rvalue.
Y( Y&& rhs ) : X( std::move( rhs ) ) {}
Other than that, the current incarnation of rvalue references are
rather harmless.
Except that learning them can be a headache... ;-) Yesterday I learned
another rule, which is that if a return statement contains an lvalue of
class type that has the same type as the functions return type, overload
resolution treats the returned object as an rvalue first. Take the following
code for example:
std::unique_ptr Object::Clone()
{
std::unique_ptr temp = ...;
// return std::move( temp );
return temp;
}
I would have thought that the above code would not compile because temp is
an lvalue and thus could not be bound to the parameter of std::unique_ptr's
move constructor, but 12.8/31 and 12.8/32 of C++0x define this as legal C++.
To make a long story short, it seems that you can really benefit from rvalue
references, but you do have to put some seat into really learning them
first.
--
Matthias Hofmann
Anvil-Soft, CEO
http://www.anvil-soft.com - The Creators of Toilet Tycoon
http://www.anvil-soft.de - Die Macher des Klomanagers
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]