123

I just found myself not fully understanding the logic of std::move().

At first, I googled it but seems like there are only documents about how to use std::move(), not how its structure works.

I mean, I know what the template member function is but when I look into std::move() definition in VS2010, it is still confusing.

the definition of std::move() goes below.

template<class _Ty> inline
typename tr1::_Remove_reference<_Ty>::_Type&&
    move(_Ty&& _Arg)
    {   // forward _Arg as movable
        return ((typename tr1::_Remove_reference<_Ty>::_Type&&)_Arg);
    }

What is weird first to me is the parameter, (_Ty&& _Arg), because when I call the function like you see below,

// main()
Object obj1;
Object obj2 = std::move(obj1);

it basically equals to

// std::move()
_Ty&& _Arg = Obj1;

But as you already know, you can not directly link a LValue to a RValue reference, which makes me think that it should be like this.

_Ty&& _Arg = (Object&&)obj1;

However, this is absurd because std::move() must work for all the values.

So I guess to fully understand how this works, I should take a look at these structs too.

template<class _Ty>
struct _Remove_reference
{   // remove reference
    typedef _Ty _Type;
};

template<class _Ty>
struct _Remove_reference<_Ty&>
{   // remove reference
    typedef _Ty _Type;
};

template<class _Ty>
struct _Remove_reference<_Ty&&>
{   // remove rvalue reference
    typedef _Ty _Type;
};

Unfortunately it's still as confusing and I don't get it.

I know that this is all because of my lack of basic syntax skills about C++. I'd like to know how these work thoroughly and any documents that I can get on the internet will be more than welcomed. (If you can just explain this, that will be awesome too).

Alex Bitek
  • 6,529
  • 5
  • 47
  • 77
Dean Seo
  • 5,486
  • 3
  • 30
  • 49
  • 34
    @NicolBolas On the contrary, the question itself shows that OP is underselling themself in that statement. It's precisely OP's *grasp* of basic syntax skills that allows them to even pose the question. – Kyle Strand Apr 16 '15 at 01:17
  • 1
    I disagree anyway - you can learn quickly or already have a good grasp of computer science or programming as a whole, even in C++, and still struggle with the syntax. It's better to spend your time learning mechanics, algorithms, etc. but rely on references to brush up on syntax as needed, than it is to be technically articulate but to have a shallow understanding of things like copy/move/forward. How are you supposed to know "when and how to use std::move when you want to move construct something" before you know what move does? – John P Mar 13 '19 at 10:54
  • I think I came here to understand how `move` works rather than how it's implemented. I find this explanation really useful: https://pagefault.blog/2018/03/01/common-misconception-with-cpp-move-semantics/. – Anton Daneyko Feb 15 '20 at 12:13

2 Answers2

192

We start with the move function (which I cleaned up a little bit):

template <typename T>
typename remove_reference<T>::type&& move(T&& arg)
{
  return static_cast<typename remove_reference<T>::type&&>(arg);
}

Let's start with the easier part - that is, when the function is called with rvalue:

Object a = std::move(Object());
// Object() is temporary, which is prvalue

and our move template gets instantiated as follows:

// move with [T = Object]:
remove_reference<Object>::type&& move(Object&& arg)
{
  return static_cast<remove_reference<Object>::type&&>(arg);
}

Since remove_reference converts T& to T or T&& to T, and Object is not reference, our final function is:

Object&& move(Object&& arg)
{
  return static_cast<Object&&>(arg);
}

Now, you might wonder: do we even need the cast? The answer is: yes, we do. The reason is simple; named rvalue reference is treated as lvalue (and implicit conversion from lvalue to rvalue reference is forbidden by standard).


Here's what happens when we call move with lvalue:

Object a; // a is lvalue
Object b = std::move(a);

and corresponding move instantiation:

// move with [T = Object&]
remove_reference<Object&>::type&& move(Object& && arg)
{
  return static_cast<remove_reference<Object&>::type&&>(arg);
}

Again, remove_reference converts Object& to Object and we get:

Object&& move(Object& && arg)
{
  return static_cast<Object&&>(arg);
}

Now we get to the tricky part: what does Object& && even mean and how can it bind to lvalue?

To allow perfect forwarding, C++11 standard provides special rules for reference collapsing, which are as follows:

Object &  &  = Object &
Object &  && = Object &
Object && &  = Object &
Object && && = Object &&

As you can see, under these rules Object& && actually means Object&, which is plain lvalue reference that allows binding lvalues.

Final function is thus:

Object&& move(Object& arg)
{
  return static_cast<Object&&>(arg);
}

which is not unlike the previous instantiation with rvalue - they both cast its argument to rvalue reference and then return it. The difference is that first instantiation can be used with rvalues only, while the second one works with lvalues.


To explain why do we need remove_reference a bit more, let's try this function

template <typename T>
T&& wanna_be_move(T&& arg)
{
  return static_cast<T&&>(arg);
}

and instantiate it with lvalue.

// wanna_be_move [with T = Object&]
Object& && wanna_be_move(Object& && arg)
{
  return static_cast<Object& &&>(arg);
}

Applying the reference collapsing rules mentioned above, you can see we get function that is unusable as move (to put it simply, you call it with lvalue, you get lvalue back). If anything, this function is the identity function.

Object& wanna_be_move(Object& arg)
{
  return static_cast<Object&>(arg);
}
Vitus
  • 11,822
  • 7
  • 37
  • 64
  • 4
    Nice answer. Although I understand that for an lvalue it is a good idea to evaluate `T` as `Object&`, I didn't know that this is really done. I would have expected `T` to also evaluate to `Object` in this case, as I thought this was the reason for introducing wrapper references and `std::ref`, or wasn't it. – Christian Rau Sep 22 '11 at 17:08
  • Is [this Wikipedia article](http://en.wikipedia.org/wiki/C%2B%2B11#Wrapper_reference) outdated/misinformed or is there a hidden difference I have not realized? – Christian Rau Sep 22 '11 at 17:43
  • 2
    There's a difference between `template void f(T arg)` (which is what is in the Wikipedia article) and `template void f(T& arg)`. The first one resolves to value (and if you want to pass reference, you have to wrap it in `std::ref`), while the second one always resolves to reference. Sadly, rules for template argument deduction are rather complex, so I cannot provide precise reasoning why `T&&` resovles to `Object& &&` (but it happens indeed). – Vitus Sep 22 '11 at 17:58
  • This is extremely well done explaining why you must cast. From reading some of the proposals and draft standards you would not pick that up. For example the demo implementation of move at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2027.html#Move_Semantics lacks the cast. – nixeagle Apr 01 '12 at 18:56
  • @nixeagle: The reason is that the proposal for rvalue references went through quite a few changes. If I'm not mistaken, the rules allowed to omit the cast at some point. – Vitus Apr 01 '12 at 19:05
  • @MarkIngram: I really meant "prvalue". :) It's a techincal term defined by the C++ standard, see http://stackoverflow.com/questions/3601602 . – Vitus Nov 20 '13 at 17:05
  • 1
    But, is there any reason that this direct approach would not work? `template T&& also_wanna_be_move(T& arg) { return static_cast(arg); }` – greggo Jan 09 '14 at 16:45
  • 1
    That explains why remove_reference is necessary, but I still don't get why the function has to take T&& (instead of T&). If I understand this explanation correctly, it shouldn't matter whether you get a T&& or T& because either way, remove_reference will cast it to T, then you'll add back the &&. So why not say you accept a T& (which semantically is what you're accepting), instead of T&& and relying on perfect forwarding to allow the caller to pass a T&? – mgiuca May 11 '14 at 04:55
  • 4
    @mgiuca: If you want `std::move` to only cast lvalues to rvalues, then yes, `T&` would be okay. This trick is done mostly for flexibility: you can call `std::move` on everything (rvalues included) and get rvalue back. – Vitus May 11 '14 at 12:53
  • As additional note (if T is a template parameter), T&& is called "the universal reference", since it binds everything. – ABu May 17 '15 at 23:21
  • The types may work out, but I was really stuck on what it means to move something in the first place. It's a misnomer, isn't it? Nothing moves when you create a reference to an existing rvalue or creating a new rvalue to refer to, etc. - the original lvalue or rvalue is still in the scope it started in, has the same address as before, etc. What would moving (the bytes of) a value mean if not copying them to their destination? – John P Mar 13 '19 at 13:18
  • I wish I could *un-see* this. lol – Robin Davies Mar 21 '22 at 23:31
4

_Ty is a template parameter, and in this situation

Object obj1;
Object obj2 = std::move(obj1);

_Ty is type "Object &"

which is why the _Remove_reference is necessary.

It would be more like

typedef Object& ObjectRef;
Object obj1;
ObjectRef&& obj1_ref = obj1;
Object&& obj2 = (Object&&)obj1_ref;

If we didn't remove the reference it would be like we were doing

Object&& obj2 = (ObjectRef&&)obj1_ref;

But ObjectRef&& reduces to Object &, which we couldn't bind to obj2.

The reason it reduces this way is to support perfect forwarding. See this paper.

Vaughn Cato
  • 63,448
  • 5
  • 82
  • 132
  • This doesn't explain everything about why the `_Remove_reference_` is necessary. For instance, if you have `Object&` as a typedef, and you take a reference to it, you still get `Object&`. Why doesn't that work with &&? There _is_ an answer to that, and it has to do with perfect forwarding. – Nicol Bolas Sep 22 '11 at 06:21
  • 2
    True. And the answer is very interesting. A & && is reduced to A &, so if we tried to use (ObjectRef &&)obj1_ref, we would get Object & instead in this case. – Vaughn Cato Sep 22 '11 at 07:00