Re: Implicit move of an lvalue
Am 04.04.2012 19:21, schrieb Alf P. Steinbach:
On 03.04.2012 22:25, Daniel Kr??gler wrote:
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.
Sorry, but I can't make any sense of that. Is e.g. unique_ptr's
constructor unique_ptr( unique_ptr&& ) to be interpreted as
"perfectly forwarding"? As I see it, even as just a default
interpretation that's utterly void of meaning or any practical
advantage.
I don't understand why you compare unique_ptr( unique_ptr&& ) with a
perfect forwarding signature as mentioned by the OP
template <typename Type>
void f(Type&& that);
Your comment seems to imply that I described both as similar or
related to each other. I'm sorry should I have not made clearer, what
I meant with "perfect forwarding". So, if the context of the
definition is missing, let me refer to the (quite old) article
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2027.html#Perfect_Forwarding
In direct response to your question: No, unique_ptr( unique_ptr&& )
and no other move-constructor is a perfectly forwarding constructor,
because it is not a single function (template) that accepts both
lvalues and rvalues and redirects to internally called functions
thereby correctly transporting the original value category (As I
described: Not exactly, but to the level that rvalue category and
lvalue category are kept).
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));
}
Neither MSVC 10.0 nor MinGW g++ 4.6.1 accepted that code. As the g++
eror mesage put it, "two or more data types in declaration of
'f'". I am sure you meant to write this instead:
template< class Type >
typename std::enable_if< !std::is_lvalue_reference<Type>::value,
void >::
type f(Type&& that)
{
A b(std::move(that));
}
Thanks for your catch-up. Actually I wanted to write
template<class Type>
typename std::enable_if<!std::is_lvalue_reference<Type>::value>::type
f(Type&& that)
{
A b(std::move(that));
}
but I missed to strike the void return type from the original code.
However, I would suggest the in my view simpler and more direct
template< class Type >
void f( Type&& that)
{
A b(std::move(that));
}
template< class Type >
void f( Type& that ); // No way (lvalue => ambiguous).
which simply catches any lvalue actual argument with the second
signature, which (in that case) produces an ambiguity error, and
just for good measure is left unimplemented.
Yes, this is a nice alternative. Personally I prefer to read directly
from the wanted signature the constraint. So what also works is the
following approach, which is a bit more complex than my original
suggestion:
template<class Type>
typename std::enable_if<!std::is_lvalue_reference<Type>::value>::type
f(Type&& that)
{
A b(std::move(that));
}
namespace details {
template<class T>
struct never {
static const bool value = false;
};
}
template<class Type>
typename std::enable_if<std::is_lvalue_reference<Type>::value>::type
f(Type&& that)
{
static_assert(details::never<Type>::value, "Sorry, no lvalues
accepted!");
}
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! ]