The following definition of a min
function
template <typename T, typename U>
constexpr auto
min(T&& t, U&& u) -> decltype(t < u ? t : u)
{
return t < u ? t : u;
}
has a problem: it seems that it's perfectly legal to write
min(10, 20) = 0;
This has been tested with Clang 3.5 and g++ 4.9.
The solution is straightforward, just use std::forward
to restore the "rvalue-ness" of the arguments, i.e. modify the body and the decltype
to say
t < u ? std::forward<T>(t) : std::forward<U>(u)
However, I'm at a loss to explain why the first definition doesn't generate an error.
Given my understanding of forwarding and universal references, both t
and u
deduce their argument types as int&&
when passed integer literals. However, within the body of min
, the arguments have names, so they are lvalues. Now, the really complicated rules for the conditional operator come into play, but I think the pertinent line is:
- Both E2 [and] E3 are glvalues of the same type. In this case, the result has the same type and value category.
and therefore the return type of operator?:
should be int&&
as well, should it not? However, (as far as I can tell) both Clang and g++ have min(int&&, int&&)
returning an lvalue reference int&
, thus allowing me to assign to the result.
Clearly there is a gap in my understanding, but I'm not sure exactly what it is that I'm missing. Can anybody explain to me exactly what's going on here?
EDIT:
As Niall correctly points out, the problem here is not with the conditional operator (which is returning an lvalue of type int&&
as expected), but with the decltype
. The rules for decltype
say
if the value category of expression is lvalue, then the decltype specifies T&
so the return value of the function becomes int&& &
, which by the reference collapsing rules of C++11 turns into plain int&
(contrary to my expected int&&
).
But if we use std::forward
, we turn the second and third arguments of operator?:
(back) into rvalues - specifically, xvalues. Since xvalues are still glvalues (are you keeping up at the back?), the same conditional operator rule applies, and we get a result of the same type and value category: that is, an int&&
which is an xvalue.
Now, when the function returns, it triggers a different decltype
rule:
if the value category of expression is xvalue, then the decltype specifies T&&
This time, the reference collapsing gives us int&& && = int&&
and, more importantly, the function returns an xvalue. This makes it illegal to assign to the return value, just as we'd like.
The Lvalue refers to a modifiable object in c++ that can be either left or right side of the assignment operator. The Rvalue refers to a value stored at an address in the memory. It can appear only on the right-hand side of the assignment operator.
Explanation: If you pass an lvalue T to enqueue , U will deduce to T& , and the forward will pass it along as an lvalue, and you'll get the copy behavior you want. If you pass an rvalue T to enqueue , U will deduce to T , and the forward will pass it along as an rvalue, and you'll get the move behavior you want.
Typically rvalues are temporary objects that exist on the stack as the result of a function call or other operation. Returning a value from a function will turn that value into an rvalue.
An lvalue refers to an object that persists beyond a single expression. An rvalue is a temporary value that does not persist beyond the expression that uses it.
The issue may be with the decltype()
rules.
This is hinted at; if the trailing return type is removed
template <typename T, typename U>
constexpr auto
min(T&& t, U&& u)
{
return t < u ? t : u;
}
and the compiler is allowed to deduce it, the return type is int
.
Use of decltype
decltype ( expression )
...
if the value category of expression is lvalue, then the decltype specifies T&
Taken from cppreference.
Since the expression involving t
and u
is an lvalue (they are lvalues - named r-value references), the return is the lvalue reference.
In this situation it leads to a potential situation where a literal could be modified. Careful use of forwarding needs to be applied when using "universal references" (or "forwarding references") and the associated reference collapsing rules.
As you have already noted, to correct the situation, the correct use of std::forward
needs to be applied and the return type will be the expected one.
For further details on std::forward
and reference collapsing can be found here on SO.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With