Case 1 :I am writing a simple move constructor:
ReaderValue::ReaderValue(ReaderValue && other)
{
moveAlloc(other);
}
The moveAlloc function prototype in the ReaderValue class is:
void moveAlloc(ReaderValue && other);
I get the error from gcc 4.8:
cannot bind 'ReaderValue' lvalue to 'ReaderValue&&'
So I need to call explicitely this in order to compile:
moveAlloc(std::move(other));
Case 2 : Now ReaderValue has a std::string stringData member
I make another constructor:
ReaderValue(std::string && otherString)
: stringData(otherString)
{
}
This works, I do not need std::move to pass otherString to the stringData constructor
Question : What is the fundamental reason why I need to explicitely call std::move to pass the rvalue to a function in the first case? The error message says other is a lvalue, whereas it does look like a rvalue reference. Why not in the second case?
(Please don't reply about the actual implementation, or why do I need to do this, blah blah... That's only a fundamental language question)
ReaderValue::ReaderValue(ReaderValue && other)
{
//other here is a lvalue(has a name) referring to a rvalue
//move alloc however takes a rvalue
moveAlloc(other);
}
that is why you have to cast your lvalue to a rvalue explicitely
moveAlloc(std::move(other)); //other now is a rvalue
please note that all std::move does is effectively a cast to rvalue.
In the second example with the string:
ReaderValue(std::string && otherString)
: stringData(otherString)
{ }
calls
std::string(const string& other);
effectively copying the string, while:
ReaderValue(std::string && otherString)
: stringData(std::move(otherString))
{ }
calls:
std::string(string&& other);
moving your string
Suggest you to read this http://thbecker.net/articles/rvalue_references/section_05.html
it'll will tell you why.
In a short, c++ regards parameter other in ReaderValue as a lvalue, but the parameter other in moveAlloc is a rvalue. So you have to convert other in ReaderValue to a rvalue when you call moveAlloc.
Related
Is there a technical reason why std::exchange does not work on std::vector::reference or is it a bug in the implementation of GCC and Clang? With MSVC it compiles fine.
I have a setup like this (minimal example)
struct Manager
{
std::vector<bool> lifeTimes;
//Should return the state before trying to kill it
bool kill(std::size_t index)
{
return std::exchange(lifeTimes[index], false);
}
};
std::exchange would make this a really nice one liner but GCC complains about:
error: cannot bind non-const lvalue reference of type ‘std::_Bit_reference&’ to an rvalue of type ‘std::vector::reference’ {aka ‘std::_Bit_reference’}
So it seams it complains about the false since only the second parameter is an rvalue
It is not a bug, MSVC compiles your code because it has an extension which enables binding temporary object (Rvalue) to non-const Lvalue reference.
Below code compiles with MSVC:
void foo(int& i) {}
foo(20); // you are passing Rvalue and it is bound to Lvalue reference
Above code doesn't compile under G++ or CLang, when you add const to make reference to
const Lvalue, it works:
void foo(const int&){}
foo(20); // you can bind Rvalue to const Lvalue reference
A few words about vector. operator[] for vector<T> where T is every type except bool returns T&:
T& vector<T>::operator[](index) // where T is not bool
For bool vector class template has specialization. Values of bool are stored to hold one bit space, because you cannot use address-of operator for one bit, vector<bool>::operator[](index) cannot return reference. vector<bool> has inner proxy class which manipulates bits (call this class as reference).
vector<bool>::reference vector<bool>::operator[](index)
^^^^^^^^^
as you see object of proxy is passed by value.
So when you call
return std::exchange(lifeTimes[index], false);
you are passing temporary objecy (Rvalue) to exchange which takes first argument by reference to non-const Lvalue. This is the cause that G++ discards this code. If you want to compile it you can explicitly create Lvalue object of proxy class and pass it:
bool kill(std::size_t index)
{
std::vector<bool>::reference proxyForBit = lifeTimes[index];
return std::exchange(proxyForBit, false);
}
According to Is a member of an rvalue structure an rvalue or lvalue?:
if E1 is lvalue, then E1.E2 is lvalue, and forward cast its argument to an rvalue only if that argument is bound to an rvalue. In function void foo(Obj &&obj) below, obj is lvalue, so obj.i is lvalue, why is std::forward<int>(obj.i) an rvalue?
class Obj
{
public:
int i;
};
void foo(int &i)
{
cout<<"foo(int&)"<<endl;
}
void foo(int &&i)
{
cout<<"foo(int&&)"<<endl;
}
void foo(Obj &&obj)
{
foo(std::forward<int>(obj.i));
foo(obj.i);
}
int main()
{
Obj obj;
foo(std::move(obj));
return 0;
}
output
foo(int&&)
foo(int&)
You're actually forwarding the wrong thing. In this function:
void foo(Obj &&obj)
{
foo(std::forward<int>(obj.i));
foo(obj.i);
}
obj has name, so it's an lvalue. obj.i is an lvalue in both cases, just in the first you're explicitly casting it to an rvalue! When forward gets a reference type, you get out an lvalue. When it gets a non-reference type, you get an rvalue. You're giving it a non-reference type, so the forward here is equivalent to: foo(std::move(obj.i)); Does that make it clearer why you get an rvalue?
The question you linked, however, is about members of rvalues. To get that, you need to turn obj itself into an rvalue:
foo(std::move(obj).i);
Here, since std::move(obj) is an rvalue, std::move(obj).i is an rvalue as well.
Regardless, using forward when taking an argument by not-forwarding-reference is a little weird. Here's a more general example:
template <class O>
void foo(O&& obj) {
foo(std::forward<O>(obj).i);
}
foo(obj); // calls foo(int&)
foo(std::move(obj)); // calls foo(int&&)
In the former case, std::forward<O>(obj) is an lvalue because O is Obj&, which makes std::foward<O>(obj).i an lvalue. In the latter case, they're both rvalues.
function void foo(Obj &&obj) below:
obj is lvalue, so obj.i is lvalue,
Hmm, do you declare obj as rvalue reference in function proto and then insist it's an lvalue?
According to the specifications of std::forward, the return type is simple an rvalue reference applied to the template type. So the return type std::forward<int> is int&& - used in this way it has exactly the same effect as std::move.
The normal recipe for using std::forward is with universal references:
template<typename T>
void f(T&& val)
{
other_func(std::forward<T>(val));
}
This would work correctly for references, as the deduced type for an lvalue reference in this case would also be an lvalue reference. In your case you're hard-coding the type (to int) rather than deducing it - the deduced type if you used the above pattern would in fact be int&, not int.
You will see that if you change foo(std::forward<int>(obj.i)) to foo(std::forward<int&>(obj.i)) you will get what you expect
"Theory" question if you will.
In order to execute/make use of the move constructor in a class, do I always have to use std::move(...) to tell the compiler that I wish to 'move' an object rather than copy it?
Are there any cases where the compiler will invoke the move constructor for me without the use of std::move? (My guess would be in function return values?)
According to cppreference.com (http://en.cppreference.com/w/cpp/language/move_constructor):
The move constructor is called whenever an object is initialized from xvalue of the same type, which includes
initialization, T a = std::move(b); or T a(std::move(b));, where b is of type T;
function argument passing: f(std::move(a));, where a is of type T and f is void f(T t);
function return: return a; inside a function such as T f(), where a is of type T which has a move constructor.
In most cases, yes std::move is needed.
The compiler will invoke the move constructor without std::move when:
returning a local variable by value
when constructing an object from an rvalue of the same type
In all other cases, use std::move. E.g.:
struct S {
std::string name;
S(std::string name) : name(std::move(name)) {}
};
and
std::unique_ptr<Base> func() {
auto p = std::make_unique<Derived>();
return std::move(p); // doesn't work without std::move
}
std::move is just a cast.
unique_ptr<int> global;
auto v = unique_ptr<int>(global); // global is a lvalue, therefore the
unique_ptr(unique_ptr<T>&v) constructor that accepts lvalue references is called.
auto v = unique_ptr<int>(std::move(global)); // move returns a &&rvalue reference, therefore the
unique_ptr(unique_ptr<T>&&v) constructor that accepts &&rvalue references is used.
When the criteria for elision of a copy operation are met and the object to be copied is designated by an lvalue, overload resolution to select the constructor for the copy is first performed as if the object were designated by an rvalue.
therefore,
unique_ptr<int> hello()
{
unique_ptr<int> local;
return local;
// local is an lvalue, but since the critera for elision is met,
// the returned object is created using local as if it was an rvalue
}
Also,
unique_ptr<int> hello = std::unique_ptr<int>();
// we have a pure rvalue in the right, therefore no std::move() cast is needed.
class outer
{
class inner
{
public:
inner() { }
inner(inner&& rhs);
}
public:
outer() { }
outer(outer&& rhs)
: m_inner(rhs.m_inner) // why is rhs.m_inner an lvalue and not an rvalue?
{ }
private:
inner m_inner;
};
Why is rhs.m_inner an lvalue in this context? If rhs is an rvalue, why is rhs.m_inner not also an rvalue?
The source text rhs refers to two different things here:
The variable rhs, an rvalue-reference to an outer object. This variable has type outer&&.
The expression rhs that evaluates the value of that variable. This expression has type outer and value category lvalue.
The lvalue/rvalue-ness of a reference variable determines to which value categories of expressions the reference can bind, it has no affect on the value category of expressions that evaluate the variable. Evaluating a reference always results in an lvalue.
If rhs was an rvalue, then rhs.m_inner would be an rvalue too. However, rhs is a named variable (doesn't matter that it's an rvalue reference), so it's an lvalue.
With reference to C++ Annotations, to call outer(outer&& rhs), one would use the code:
outer out((outer)outer()/*0*/)/*1*/;
Which at 0 constructs an anonymous object of type outer, and at 1 it constructs an object of type outer with the name out. (The (outer) is there to prevent out form being an outer(outer (*)()))
See the anonymous there? Now consider the definition of outer(outer&& rhs):
outer(outer && rhs) : m_inner(rhs.m_inner) {}
outer(outer &&) has 1 argument of type outer && named rhs.
Now, there is a perceivable difference between the statement 0 in ex. 1 and the first parameter: the former doesn't have a name, the latter does, hence removing the anonimity of the object. Now since the object has a name it is just a lvalue reference (which allows people to use a construct-by-swap idiom). The problem arises, though, when someone needs to use it as a rvalue reference. For that the
template<class T>
typename std::remove_reference<T>::type&& move(T&& t);
function was created. What's it do? It "obtains an rvalue reference to its argument and converts it to an xvalue" (more on all sorts of values here), which is exactly what we need! So, the final code could be:
#include <utility>
class outer {
class inner {
public:
inner() {}
inner(inner && rhs) {}
};
public:
outer() {}
outer(outer && rhs) : m_inner(std::move(rhs.m_inner)) {}
private:
inner m_inner;
};
Note the #include <utility> and std::move() call.
I have recently wrapped my mind around the C++0x's concepts of glvalues, xvalues and prvalues, as well as the rvalue references. However, there's one thing which still eludes me:
What is "an rvalue reference to function type"? It is literally mentioned many times in the drafts. Why was such a concept introduced? What are the uses for it?
I hate to be circular, but an rvalue reference to function type is an rvalue reference to function type. There is such a thing as a function type, e.g. void (). And you can form an rvalue reference to it.
In terms of the classification system introduced by N3055, it is an xvalue.
Its uses are rare and obscure, but it is not useless. Consider for example:
void f() {}
...
auto x = std::ref(f);
x has type:
std::reference_wrapper<void ()>
And if you look at the synopsis for reference_wrapper it includes:
reference_wrapper(T&) noexcept;
reference_wrapper(T&&) = delete; // do not bind to temporary objects
In this example T is the function type void (). And so the second declaration forms an rvalue reference to function type for the purpose of ensuring that reference_wrapper can't be constructed with an rvalue argument. Not even if T is const.
If it were not legal to form an rvalue reference to function, then this protection would result in a compile time error even if we did not pass an rvalue T to the constructor.
In the old c++ standard the following is forbidden:
int foo();
void bar(int& value);
int main()
{
bar(foo());
}
because the return type of foo() is an rvalue and is passed by reference to bar().
This was allowed though with Microsoft extensions enabled in visual c++ since (i think) 2005.
Possible workarounds without c++0x (or msvc) would be declaring
void bar(const int& value);
or using a temp-variable, storing the return-value of foo() and passing the variable (as reference) to bar():
int main()
{
int temp = foo();
bar(temp);
}