Based mostly on Thomas Becker's article
http://thbecker.net/articles/rvalue_references/section_01.html ...


What is the rvalue reference and why we need it?


I many earlier languages assignment works in the following way:

  <variable> := <expression>

like

  x := y + 5;


In C/C++ however there might be expressions on the left side of =

  <expression> = <expression>

like

  *++p = *++q;  // likely ok if p is pointer, except p is const *


But not all kind of expressions may appear on the left hand side:

  y + 5 = x;  // likely error except some funny operator+


"Left value" is originated to C language: an l value is an expression
that may appear on the left hand side of an assignment. "Right value"
is anything else.

Basically left-value identified a writeable memory location in C.
In C++ this is a bit more complex, but here is a widely acecpted
definition:


An "lvalue" is an expression that refers to a memory location and allows
us to take the address of that memory location via the & operator.
An "rvalue" is an expression that is not an "lvalue"



These are lvalues

int  i = 42;
int &j = i;
int *p = &i;

 i = 99;
 j = 88;
*p = 77;

int *fp() { return &i; } // returns pointer to i: lvalue
int &fr() { return i; }  // returns reference to i: lvalue

*fp() = 66;  // i = 66
 fr() = 55;  // i = 55 


These are rvalues

int f() { int k = i; return k; } // returns rvalue

  i = f();  // ok
  p = &f(); // bad: can't take address of rvalue
f() = i;    // bad: can't use rvalue on lefthand side

A rigorous definition of lvalue and rvalue:
http://accu.org/index.php/journals/227



C and C++ has value semantics -- when we use assignment we copy by default.


Array a, b, c, d, e;

a = b + c + d + e;


This will generate the following pseudo-code:


// pseudocode for a = b + c + d + e

double* _t1 = new double[N];
for ( int i=0; i<N; ++i)
    _t1[i] = b[i] + c[i];

double* _t2 = new double[N];
for ( int i=0; i<N; ++i)
    _t2[i] = _t1[i] + d[i];

double* _t3 = new double[N];
for ( int i=0; i<N; ++i)
    _t3[i] = _t2[i] + e[i];

for ( int i=0; i<N; ++i)
    a[i] = _t3[i];

delete [] _t3;
delete [] _t2;
delete [] _t1;



Performace problems

- For small arrays new  andi delete result poor performance: 1/10 of C.
- For medium arrays, overhead of extra loops and memory access add +50%
- For large arrays, the cost of the temporaries are the limitations

This has been investigated by Todd Veldhuizen and has led to C++ template
metaprogramming and expression templates.


It would be nice not to create the temporaries, but steal the resources of
the arguments of operator+()

But!
We can destroy only the temporaries: we should keep the original resources
for the b, c, d, e variables. How can we distinguis between variables and
unnamed temporaries? --> overloading

Overloading --> We need a separate type!
What kind of requirements we have for this type?

1. should be a reference type - otherwise we gain nothing

2. if there is an overload between ordinary reference and this new type
   then rvalues should prefer the new type and lvalues the ordinary reference




Rvalue reference:

X &&


Old kind of references now are called as lvalue references:

X &


void f(X&  arg_)  // lvalue reference parameter
void f(X&& arg_)  // rvalue reference parameter


X x;
X g();

f(x);   // lvalue argument --> f(X&)      
f(g()); // rvalue argument --> f(X&&)



We can overload copy constructor and assignmnet operator overloads:


class X
{
public:
  X(const X& rhs);
  X(X&& rhs);

  X& operator=(const X& rhs);
  X& operator=(X&& rhs);
private:


};


X& X::operator=(const X& rhs)
{
  // free old resources than copy resource from rhs
  return *this;
}

X& X::operator=(X&& rhs)  // draft version, will be revised later
{
  // free old resources than move resource from rhs
  // leave rhs in a destructable state
  return *this;
}


Reverse compatibility


If we implement the old-style memberfunctions with lvalue reference parameters
but do not implement the evalue reference overloading versions we keep the
old behaviour -> we can gradually move to move semantics.


However, if we implement "only" the rvalue operations than we cannot call
these on lvalues -> no default lvalue-copy constructor or operator= will
be generated.





std::move()


Can we use move semantic on lvalue  Do we need this


template<class T>
void swap(T& a, T& b)
{
  T tmp(a);
  a = b;
  b = tmp;
}

X a, b;
:
swap(a, b);


By default, this swap implementation will use copy semantic.
To enforce move semantic we should use std::move().


template<class T>
void swap(T& a, T& b)
{
  T tmp(std::move(a));
  a = std::move(b);
  b = std::move(tmp);
}

X a, b;
:
swap(a, b);


std::move() converts its argument to rvalue reference, does not do
anything else. We should think std::move as "rvalue reference cast".


"The committee shall make no rule that prevents C++ programmers from 
shooting themselves in the foot." 

First Amendment to the C++ Standard quoted by Thomas Becker
http://thbecker.net/articles/rvalue_references/section_04.html  

Therefore we can use std::move() with extra care.


-- Usually std::move() has positive effect on performance,
   as many standard algorithm utilize move semantics.

-- Sometimes we have to use std::move().
   There are types moveable but not copyable:

   std::unique_pointer
   std::fstream
   std::thread




X&& f();

void g(X&& arg_)
{
  X var1 = arg_;   // copy or move?     
  X var2 = f();    // copy or move?
}


Since arg_ is declared as rvalue reference we might think that here
X::X(X&& rhs) will be called. But not always:

Things that are declared as rvalue reference can be lvalues or rvalues.
Anything has a "name" is an "lvalue" otherwise it is an "lvalue".

Therefore in the var1 example above X::X(const X& will be called),
and in the var2 example X::X(&&) is called.

Philosophy:
After X var1 = arg_; arg_ is still in scope and can be available.


X&& f();

void g(X&& arg_)
{
  X var1 = arg_;   // copy  X::X(const X&)
  X var2 = f();    // move  X::X(X&&)
}                  // arg_ goes out of scope here



If-it-has-a-name-rule:


class Base
{
public:
  Base(const Base& rhs); // non-move semantics
  Base(Base&& rhs);      // move semantics      
  :
};


class Derived : public Base
{
  Derived(const Derived& rhs);  // non-move semantics
  Derived(Derived&& rhs);       // move semantics
  :
};


Derived(Derived const & rhs) : Base(rhs)  // non-move semantics
{
  // Derived-specific stuff
}

// wrong
Derived(Derived&& rhs) : Base(rhs) // wrong: rhs is an lvalue
{
  // Derived-specific stuff
}

// good
Derived(Derived&& rhs) : Base(std::move(rhs)) // good, calls Base(Base&& rhs)
{
  // Derived-specific stuff
}