Binding lvalue to rvalue reference -- g++ bug? - c++

Question

As an answer to another question I wanted to post the following code (that is, I wanted to post code based on this idea):
#include <iostream>
#include <utility> // std::is_same, std::enable_if
using namespace std;
template< class Type >
struct Boxed
{
Type value;
template< class Arg >
Boxed(
Arg const& v,
typename enable_if< is_same< Type, Arg >::value, Arg >::type* = 0
)
: value( v )
{
wcout << "Generic!" << endl;
}
Boxed( Type&& v ): value( move( v ) )
{
wcout << "Rvalue!" << endl;
}
};
void function( Boxed< int > v ) {}
int main()
{
int i = 5;
function( i ); //<- this is acceptable
char c = 'a';
function( c ); //<- I would NOT like this to compile
}
However, while MSVC 11.0 chokes at the last call, as it IHMO should, MinGW g++ 4.7.1 just accepts it, and invokes the constructor with rvalue reference formal argument.
It looks to me as if an lvalue is bound to an rvalue reference. A glib answer could be that the lvalue is converted to rvalue. But the question is, is this a compiler bug, and if it’s not, how does the Holy Standard permit this?
EDIT: I managed to reduce it all to the following pretty short example:
void foo( double&& ) {}
int main()
{
char ch = '!';
foo( ch );
}
Fails to compile with MSVC 11.0, does compile with MinGW 4.7.1, which is right?

Answer 1

I haven't check the spec but I guess char can be automatically cast to int. Since you cannot assign anything (it's r-value) the R-value to temporary variable of type int (to be more explicit to (int)c value) will be passed.

Answer 2

I discovered that N3290 (identical to C++11 standard) contains non-normative example of binding double&& to rvalue generated from int lvalue, and the updated wording in §8.5.3
“If T1 is reference-related to T2 and the reference is an rvalue reference,
the initializer expression shall not be an lvalue.”
The rules were reportedly designed to avoid inefficient extra copying. Although I fail to see how such copying could not be optimized away. Anyway, whether the rationale is reasonable or not – and it certainly doesn't seem as a reasonable effect! – the following code is allowed, and compiles with both MSVC 11 and MinGW g++ 4.7:
struct Foo {};
struct Bar { Bar( Foo ) {} };
void ugh( Bar&& ) {}
int main()
{
Foo o;
ugh( o );
}
So apparently MSVC 11 is wrong in not permitting the lvalue -> rvalue conversion.
EDIT: I learned that there is Defect Report about this issue, DR 1414. The Feb 2012 conclusion was that the current behavior specification is “correct”, presumably with respect to how well it reflects the intention. It is however reportedly still discussed in the committee, presumably with respect to the practicality of the intention.

Answer 3

Presumably you agree this is valid?
void foo( double ) {} // pass-by-value
int main()
{
char ch = '!';
foo( ch );
}
There's an implicit conversion from char to double, so the function is viable.
It's the same in the example in your edited question, there's an implicit conversion that produces a temporary (i.e. an rvalue) and the rvalue-reference argument binds to that temporary. You can make that conversion explicit if you prefer:
void foo( double&& ) {} // pass-by-reference
int main()
{
char ch = '!';
foo( double(ch) );
}
but that doesn't really change anything in this case. That would be necessary if double -> char could only be converted explicitly (e.g. for class types with explicit constructors or explicit conversion operators) but double to char is a valid implicit conversion.
The "an rvalue-reference cannot bind to an lvalue" rule you're thinking of refers to binding a T&& to a T lvalue, and that rule isn't broken because the double&& doesn't bind to the char, it binds to a temporary created by the implicit conversion.
That rule doesn't only exist to prevent unnecessary extra copying, but to fix a real safety problem that existed with the previous rules, see http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2008/n2812.html
Edit: It was asked whether this behaviour is desirable on the committee reflector (see DR 1414) and it was decided that yes, this behaviour is intended and is correct. One of the arguments used to reach that position was that this code is more efficient with the current rules:
std::vector<std::string> v;
v.push_back("text");
With the current rules a temporary std::string is created by an implicit conversion, then std::vector<T>::push_back(T&&) is called, and the temporary is moved into the vector. If that push_back overload Wasn't viable for the result of a conversion then the code above would call std::vector<T>::push_back(const T&) which would cause a copy. The current rules make this real-world use case more efficient. If the rules said rvalue-refs cannot bind to the result of implicit conversions you would have to change the code above to get the efficiency of a move:
v.push_back( std::string{"text"} );
IMHO it makes no sense to have to explicitly construct a std::string when that constructor is not explicit. I want consistent behaviour from explicit/implicit constructors, and I want the first push_back example to be more efficient.