I&#39;ve been looking into some of the new features of C++11 and one I&#39;ve noticed is the double ampersand in declaring variables, like `T&amp;&amp; var`.

For a start, what is this beast called? I wish Google would allow us to search for punctuation like this.

What exactly does it _mean?_

At first glance, it appears to be a double reference (like the C-style double pointers `T** var`), but I&#39;m having a hard time thinking of a use case for that.


What does T&amp;&amp; (double ampersand) mean in C++11?

In perfect forwarding, `std::forward` is used to convert the named rvalue references `t1` and `t2` to unnamed rvalue references. What is the purpose of doing that? How would that affect the called function `inner` if we leave `t1` &amp; `t2` as lvalues?
    
    template &lt;typename T1, typename T2&gt;
    void outer(T1&amp;&amp; t1, T2&amp;&amp; t2) 
    {
        inner(std::forward&lt;T1&gt;(t1), std::forward&lt;T2&gt;(t2));
    }


What are the main purposes of using std::forward and which problems it solves?

I&#39;m trying to understand rvalue references and move semantics of C++11.

What is the difference between these examples, and which of them is going to do no vector copy?

## First example ##
    std::vector&lt;int&gt; return_vector(void)
    {
        std::vector&lt;int&gt; tmp {1,2,3,4,5};
        return tmp;
    }
    
    std::vector&lt;int&gt; &amp;&amp;rval_ref = return_vector();

## Second example ##
    std::vector&lt;int&gt;&amp;&amp; return_vector(void)
    {
        std::vector&lt;int&gt; tmp {1,2,3,4,5};
        return std::move(tmp);
    }
    
    std::vector&lt;int&gt; &amp;&amp;rval_ref = return_vector();

## Third example ##
    std::vector&lt;int&gt; return_vector(void)
    {
        std::vector&lt;int&gt; tmp {1,2,3,4,5};
        return std::move(tmp);
    }
    
    std::vector&lt;int&gt; &amp;&amp;rval_ref = return_vector();


C++11 rvalues and move semantics confusion (return statement)

So, after watching [this wonderful lecture][1] on rvalue references, I thought that every class would benefit of such a &quot;move constructor&quot;, `template&lt;class T&gt; MyClass(T&amp;&amp; other)` ***edit*** and of course a &quot;move assignment operator&quot;, `template&lt;class T&gt; MyClass&amp; operator=(T&amp;&amp; other)` as Philipp points out in his answer, if it has dynamically allocated members, or generally stores pointers. Just like you *should* have a copy-ctor, assignment operator and destructor if the points mentioned before apply.
Thoughts?

  [1]: http://channel9.msdn.com/shows/Going+Deep/C9-Lectures-Introduction-to-STL-with-Stephan-T-Lavavej/

Rule-of-Three becomes Rule-of-Five with C++11?

How do I capture by move (also known as rvalue reference) in a C++11 lambda?

I am trying to write something like this:

    std::unique_ptr&lt;int&gt; myPointer(new int);
    
    std::function&lt;void(void)&gt; example = [std::move(myPointer)]{
       *myPointer = 4;
    };



Move capture in lambda

for example:

    Beta_ab&amp;&amp;
    Beta::toAB() const {
    	return move(Beta_ab(1, 1));
    }



Is returning by rvalue reference more efficient?

The C++11 `std::move(x)` function doesn&#39;t really move anything at all.  It is just a cast to r-value.  Why was this done?  Isn&#39;t this misleading?

Why is `std::move` named `std::move`?

I was just writing a generic object factory and using the boost preprocessor meta-library to make a variadic template (using 2010 and it doesn&#39;t support them). My function uses rval references and `std::forward` to do perfect forwarding and it got me thinking...when C++0X comes out and I had a standard compiler I would do this with real variadic templates.  How though, would I call `std::forward` on the arguments?

    template &lt;typename ...Params&gt;
    void f(Params... params) // how do I say these are rvalue reference?
    {
        y(std::forward(...params)); //? - I doubt this would work.
    }

Only way I can think of would require manual unpacking of ...params and I&#39;m not quite there yet either. Is there a quicker syntax that would work?


How would one call std::forward on all arguments in a variadic function?

I guess not, but I would like to confirm. Is there any use for `const Foo&amp;&amp;`, where `Foo` is a class type?

Do rvalue references to const have any use?

I was just playing around with g++ 4.7 (one of the later snapshots) with -std=c++11 enabled. I tried to compile some of my existing code base and one case that failed somewhat confuses me.

I would appreciate if someone can explain what is going on.

Here&#39;s the code:

    #include &lt;utility&gt;
    #include &lt;iostream&gt;
    #include &lt;vector&gt;
    #include &lt;string&gt;

    int main ( )
    {
        std::string s = &quot;abc&quot;;

        // 1 ok
        std::pair &lt; std::string, int &gt; a = std::make_pair ( s, 7 );
        
        // 2 error on the next line
        std::pair &lt; std::string, int &gt; b = std::make_pair &lt; std::string, int &gt; ( s, 7 );

        // 3 ok
        std::pair &lt; std::string, int &gt; d = std::pair &lt; std::string, int &gt; ( s, 7 );

        return 0;
    }

I understand that make_pair is _meant_ to be used as the (1) case (if I specify the types, then I might as well use (3)), but I don&#39;t understand why it&#39;s failing in this case.

The exact error is:
 
```
test.cpp: In function ‘int main()’:
    test.cpp:11:83: error: no matching function for call to ‘make_pair(std::string&amp;, int)’
    test.cpp:11:83: note: candidate is:
    In file included from /gcc4.7/usr/local/lib/gcc/i686-pc-linux-gnu/4.7.0/../../../../include/c++/4.7.0/utility:72:0,
                 from test.cpp:1:
    /gcc4.7/usr/local/lib/gcc/i686-pc-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/stl_pair.h:274:5:
note: template&lt;class _T1, class _T2&gt; constexpr std::pair&lt;typename std::__decay_and_strip&lt;_T1&gt;::__type, typename std::__decay_and_strip&lt;_T2&gt;::__type&gt; std::make_pair(_T1&amp;&amp;, _T2&amp;&amp;)
    /gcc4.7/usr/local/lib/gcc/i686-pc-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/stl_pair.h:274:5:
note:   template argument deduction/substitution failed:
    test.cpp:11:83: note:   cannot convert ‘s’ (type ‘std::string {aka std::basic_string&lt;char&gt;}’) to type ‘std::basic_string&lt;char&gt;&amp;&amp;’
```
Again, the question here is just &quot;what&#39;s going on?&quot; I know that I can fix the problem by removing the template specification, but I just want to know what&#39;s failing here under the covers.

- g++ 4.4 compiles this code with no problems.
- Removing -std=c++11 also compiles with code with no problems.


C++11 make_pair with specified template parameters doesn&#39;t compile

Is there a reason when a function **should return a RValue Reference**? A technique, or trick, or an idiom or pattern?

    MyClass&amp;&amp; func( ... );

I am aware of the danger of [returning references][1] in general, but sometimes we do it anyway, don&#39;t we? `T&amp; T::operator=(T)` is just one idiomatic example. But how about `T&amp;&amp; func(...)`? Is there any general place where we would gain from doing that? Probably different when one writes library or API code, compared to just client code?

  [1]: https://stackoverflow.com/questions/3033689/question-about-r-value-in-c0x

Is there any case where a return of a RValue Reference (&amp;&amp;) is useful?

Since we have move semantics in C++, nowadays it is usual to do

    void set_a(A a) { _a = std::move(a); }

The reasoning is that if `a` is an rvalue, the copy will be elided and there will be just one move. 

But what happens if `a` is an lvalue? It seems there will be a copy construction and then a move assignment (assuming A has a proper move assignment operator). Move assignments can be costly if the object has too many member variables. 

On the other hand, if we do

    void set_a(const A&amp; a) { _a = a; }

There will be just one copy assignment. Can we say this way is preferred over the pass-by-value idiom if we will pass lvalues?


Is the pass-by-value-and-then-move construct a bad idiom?

For example, stdlibc++ has the following:

    unique_lock&amp; operator=(unique_lock&amp;&amp; __u)
    {
        if(_M_owns)
            unlock();
        unique_lock(std::move(__u)).swap(*this);
        __u._M_device = 0;
        __u._M_owns = false;
        return *this;
    }
Why not just assign the two __u members to *this directly? Doesn&#39;t the swap imply that __u is assigned the *this members, only to later have then assigned 0 and false... in which case the swap is doing unnecessary work.  What am I missing?
(the unique_lock::swap just does an std::swap on each member)

Why do some people use swap for move assignments?

I have a proxy container class around a movable object, and wish the proxy to be able to implicitly yield an rvalue reference to the underlying object, but only when the proxy itself is being moved. 

I believe that I will be able to implement this behaviour as per proposal n2439 [&quot;Extending move semantics to *this&quot;](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2439.htm), but it is not yet available in a release of gcc and won&#39;t be for a while. 

The code below is what I am ultimately aiming for, but is not currently possible. Until this feature is available to me, are there any equivalent workarounds? 

    template&lt; class T &gt;
    struct movable_proxy {
        operator T&amp;&amp;() &amp;&amp; {
            return std::move(value);
        }

        operator const T&amp;() const&amp; {
            return value;
        }
    
    private:
        T value;
    };

Workarounds for no &#39;rvalue references to *this&#39; feature

Let&#39;s take the following method as an example:

    void Asset::Load( const std::string&amp; path )
    {
        // complicated method....
    }


General use of this method would be as follows:

    Asset exampleAsset;
    exampleAsset.Load(&quot;image0.png&quot;);

Since we know most of the time the Path is a temporary rvalue, does it make sense to add an Rvalue version of this method? And if so, is this a correct implementation;

    void Asset::Load( const std::string&amp; path )
    {
        // complicated method....
    }
    void Asset::Load( std::string&amp;&amp; path )
    {
         Load(path); // call the above method
    }


Is this a correct approach to writing rvalue versions of methods?

Correct usage of rvalue references as parameters

Given all three functions, this call is ambiguous.

    int f( int );
    int f( int &amp;&amp; );
    int f( int const &amp; );
    
    int q = f( 3 );

Removing `f( int )` causes both Clang and GCC to prefer the rvalue reference over the lvalue reference. But instead removing either reference overload results in ambiguity with `f( int )`.

Overload resolution is usually done in terms of a strict partial ordering, but `int` seems to be equivalent to two things which are not equivalent to each other. What are the rules here? I seem to recall a defect report about this.

Is there any chance `int &amp;&amp;` may be preferred over `int` in a future standard? The reference must bind to an initializer, whereas the object type is not so constrained. So overloading between `T` and `T &amp;&amp;` could effectively mean &quot;use the existing object if I&#39;ve been given ownership, otherwise make a copy.&quot; (This is similar to pure pass-by-value, but saves the overhead of moving.) As these compilers currently work, this must be done by overloading `T const &amp;` and `T &amp;&amp;`, and explicitly copying. But I&#39;m not even sure even that is strictly standard.

Overload resolution between object, rvalue reference, const reference

I&#39;ve been watching Scott Meyers&#39; [talk on Universal References](http://channel9.msdn.com/Shows/Going+Deep/Cpp-and-Beyond-2012-Scott-Meyers-Universal-References-in-Cpp11) from the C++ and Beyond 2012 conference, and everything makes sense so far. However, an audience member asks a question at around 50 minutes in that I was also wondering about. Meyers says that he does not care about the answer because it is non-idiomatic and would silly his mind, but I&#39;m still interested.

The code presented is as follows:

    // Typical function bodies with overloading:
    void doWork(const Widget&amp; param)   // copy
    {
      // ops and exprs using param
    }
    void doWork(Widget&amp;&amp; param)        // move
    {
      // ops and exprs using std::move(param)
    }

    // Typical function implementations with universal reference:
    template &lt;typename T&gt;
    void doWork(T&amp;&amp; param)             // forward =&gt; copy and move
    {
      // ops and exprs using std::forward&lt;T&gt;(param)
    }

The point being that when we take an rvalue reference, we know we have an rvalue, so we should `std::move` it to preserve the fact that it&#39;s an rvalue. When we take a universal reference (`T&amp;&amp;`, where `T` is a deduced type), we want `std::forward` to preserve the fact that it may have been an lvalue or an rvalue.

So the question is: since `std::forward` preserves whether the value passed into the function was either an lvalue or an rvalue, and `std::move` simply casts its argument to an rvalue, could we just use `std::forward` everywhere? Would `std::forward` behave like `std::move` in all cases where we would use `std::move`, or are there some important differences in behaviour that are missed out by Meyers&#39; generalisation?

I&#39;m not suggesting that anybody should do it because, as Meyers correctly says, it&#39;s completely non-idiomatic, but is the following also a valid use of `std::move`:

    void doWork(Widget&amp;&amp; param)         // move
    {
      // ops and exprs using std::forward&lt;Widget&gt;(param)
    }

Can I typically/always use std::forward instead of std::move?

What is the meaning of the following line? Why is this allowed as 0 is an r-value and not a variable name? What is the significance of `const` in this statement?

    const int &amp;x = 0;

Initialization of a constant reference with a number

It seems the main advice concerning C++0x&#39;s rvalues is to add move constructors and move operators to your classes, until compilers default-implement them.

But waiting is a losing strategy if you use VC10, because automatic generation probably won&#39;t be here until VC10 SP1, or in worst case, VC11. Likely, the wait for this will be measured in years.

Here lies my problem. Writing all this duplicate code is not fun. And it&#39;s unpleasant to look at. But this is a burden well received, for those classes deemed slow. Not so for the hundreds, if not thousands, of smaller classes.

::sighs:: C++0x was supposed to let me write *less* code, not more!

And then I had a thought. Shared by many, I would guess.

Why not just pass everything by value? Won&#39;t std::move + copy elision make this nearly optimal?

## Example 1 - Typical Pre-0x constructor ##

    OurClass::OurClass(const SomeClass&amp; obj) : obj(obj) {}
 
    SomeClass o;
    OurClass(o);            // single copy
    OurClass(std::move(o)); // single copy
    OurClass(SomeClass());  // single copy

***Cons:*** A wasted copy for rvalues.


## Example 2 - Recommended C++0x? ##
 
    OurClass::OurClass(const SomeClass&amp; obj) : obj(obj) {}
    OurClass::OurClass(SomeClass&amp;&amp; obj) : obj(std::move(obj)) {}

    SomeClass o;
    OurClass(o);            // single copy
    OurClass(std::move(o)); // zero copies, one move
    OurClass(SomeClass());  // zero copies, one move

***Pros:*** Presumably the fastest.   
***Cons:*** Lots of code!


## Example 3 - Pass-by-value + std::move ##

    OurClass::OurClass(SomeClass obj) : obj(std::move(obj)) {}
 
    SomeClass o;
    OurClass(o);            // single copy, one move
    OurClass(std::move(o)); // zero copies, two moves
    OurClass(SomeClass());  // zero copies, one move

***Pros:*** No additional code.   
***Cons:*** A wasted move in cases 1 &amp; 2. Performance will suffer greatly if `SomeClass` has no move constructor.
***

What do you think? Is this correct? Is the incurred move a generally acceptable loss when compared to the benefit of code reduction?

All Rvalue Reference Solutions on Gang of Coders

Total of 19 Rvalue Reference Solutions

What does T&& (double ampersand) mean in C++11?