Re: Implicit move of an lvalue
Am 03.04.2012 20:36, schrieb Kaba:
Have a look at the following code:
class A
{
public:
A() {}
A(const A& that) {}
A(A&& that) {}
};
template<typename Type>
void f(Type&& that)
{
A b(std::move(that));
}
int main()
{
A a;
f(a); // Compiles.
return 0;
}
It is my understanding that 'b' gets move-constructed from 'a' in f(a):
* 'a' is an lvalue, and so Type = A& in f(a).
* By the reference collapsing rules, A& && = A&.
* Thus the type of 'that' is A&.
* 'that' is an lvalue, but gets converted to an rvalue by std::move.
* Therefore, 'b' gets move-constructed from 'a'.
I agree with these conclusions.
Now consider how close this is to the case banned by the standard, that
rvalue references can not bind to lvalue references:
void g(A&& a)
{
A b(std::move(a));
}
A a;
g(a); // Error.
This is for a good reason, of course, because we usually have further
use for an lvalue afterwards.
I am feeling unease about the template moving from an lvalue as
something that might cause potential traps. What do you think of it?
I tend to disagree. One needs to be aware that the "perfectly
forwarding" signature has been introduced for a very specific reason:
To forward any argument based on it's value category thus conserving
the value category (at least to the level of xvalue vs. lvalue). If
you are working with perfect forwarding signatures, you should
*always* use std::forward, not std::move. With this rule in mind,
there is only little that can go wrong.
Alternatively, if you don't want to have this effect, I suggest to
constrain the function template to the value category you wish to
accept. E.g. if f is supposed to accept *only* rvalues, this is easy
to realize by imposing
template<class Type>
typename std::enable_if<!std::is_lvalue_reference<Type>::value>::type
void f(Type&& that)
{
A b(std::move(that));
}
If we could turn back time, a better solution of this problem could
have been to select a different syntax for perfect forwarding, e.g.
template <typename Type>
void f(Type&&& that);
Alas, it is too late for this design and we have to arrange with the
current state.
HTH & Greetings from Bremen,
Daniel Kr??gler
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]