Lvalue to rvalue reference binding

Question

The compiler keeps complaining I'm trying to bind an lvalue to an rvalue reference, but I cannot see how. I'm new to C++11, move semantics, etc., so please bear with me.

I have this function:

template <typename Key, typename Value, typename HashFunction, typename Equals>
Value& FastHash<Key, Value, HashFunction, Equals>::operator[](Key&& key)
{
    //  Some code here...

    Insert(key, Value()); // Compiler error here

    //   More code here.
}

which calls this method:

template <typename Key, typename Value, typename HashFunction, typename Equals>
void FastHash<Key, Value, HashFunction, Equals>::Insert(Key&& key, Value&& value)
{
    // ...
}

I keep getting errors like the following:

cannot convert argument 1 from 'std::string' to 'std::string &&'

on the Insert() call. Isn't key defined as an rvalue in the operator overload? Why is it being reinterpreted as an lvalue?

score 42 · Accepted Answer · edited Mar 27 '23 at 22:15

42

Insert(key, Value()); // Compiler error here

key here is Key&& key - this is an lvalue! It has a name, and you can take its address. It's just that type of that lvalue is "rvalue reference to Key".

You need to pass in an rvalue, and for that you need to use std::move:

Insert(std::move(key), Value()); // No compiler error any more

I can see why this is counter-intuitive! But once you distinguish between a rvalue reference (which is a reference bound to an rvalue) and an actual rvalue, it becomes clearer.

Edit: the real problem here is using rvalue references at all. It makes sense to use them in a function template where the type of the argument is deduced, because this allows the argument to bind to either an lvalue reference or an rvalue reference, due to reference collapsing rules. See this article and video for why: http://isocpp.org/blog/2012/11/universal-references-in-c11-scott-meyers

However, in this case the type of Key is not deduced when the function is called, as it has already been determined by the class when you instantiated FastHash<std::string, ... >. Thus you really are prescribing the use of rvalue references, and thus using std::move fixes the code.

I would change your code to that the parameters are take by value:

template <typename Key, typename Value, typename HashFunction, typename Equals>
Value& FastHash<Key, Value, HashFunction, Equals>::operator[](Key key)
{
    //  Some code here...

    Insert(std::move(key), Value());

    //   More code here.
}

template <typename Key, typename Value, typename HashFunction, typename Equals>
void FastHash<Key, Value, HashFunction, Equals>::Insert(Key key, Value value)
{
    // ...
}

Don't worry too much about extra copies due to use of value arguments - these are frequently optimised out by the compiler.

edited Mar 27 '23 at 22:15

KY Lu

409
7
12

answered Dec 14 '13 at 12:56

2

Isn't the type of the lvalue just "Key"? In what way is the rvalue-reference-ness still preserved? – Dec 14 '13 at 12:59
This works, but I'm not sure I understand the issue that hvd has raised. Could you explain? – Kristian D'Amato Dec 14 '13 at 13:09
@hvd It is preserved because there is no argument type deduction going on her - see my edit. – Dec 14 '13 at 13:17
2

@polkadotcadaver I deleted my answer, because yours does a far better job. The question I had was a language lawyery question. The parameter `key` has type `Key&&`, but unless my understanding of C++ is wrong here, the *expression* `key` is an lvalue of type `Key`, not an lvalue of type `Key&&`. – Dec 14 '13 at 13:27
@hvd I see what you mean, interesting. I will have to do some digging to answer that! In this case, of course, it's the fact that it's an lvalue at all which is the issue. – Dec 14 '13 at 13:29
2

@hvd You're right; *lvalueness* is a property of an expression, and expressions don't have reference type, see [expr]/5. – dyp Dec 14 '13 at 13:32
Thanks guys. I will pick the answer shortly. I think I need a primer on rvalues and move semantics, haha. When something new happens with a language, I trip over my feet trying to get the new features used EVERYWHERE in my code. I guess that wasn't called for here. – Kristian D'Amato Dec 14 '13 at 13:37
@polkadotcadaver The reason why `key` is an lvalue is because it's an *id-expression* referring to a variable, see [expr.prim.general]/8. Essentially, all *id-expressions* but enumerators (and maybe some other) are lvalues. – dyp Dec 14 '13 at 13:37
@DyP, are those references to the C++ standard and/or are they available online? – Kristian D'Amato Dec 14 '13 at 13:39
3

@KristianD'Amato Yes; for C++11, I'm typically using [draft n3485](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3485.pdf), which is publicly available for free, and incorporates some fixes to the Standard (which itself is not free). For the most recent draft, including C++1y features, you can use the [cplusplus draft github repository](https://github.com/cplusplus/draft). – dyp Dec 14 '13 at 13:42
@polkadotcadaver If you don't need a copy of the `key`, you could (should) take it by `const&`. – dyp Dec 14 '13 at 13:47
@DyP You're right, I'm assuming too much about the "other code". – Dec 14 '13 at 13:51
@dyp An variable alone is also an expression, but variable can certainly have reference type. But as you commented, expressions don't have reference type. How to reconcile variable type and variable-name-alone expression type? I asked a question on [here](http://stackoverflow.com/questions/36349360/c-type-and-value-category-for-expression-and-variable) – Rich Apr 01 '16 at 16:38
The type of the lvalue `key` is `Key`, not "rvalue reference to key". An expression never has reference type. – M.M Apr 02 '17 at 21:12

Lvalue to rvalue reference binding

1 Answers1

Linked