10

The implementation of std::move basically looks like this:

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

Note that the parameter of std::move is a universal reference (also known as a forwarding reference, but we're not forwarding here). That is, you can std::move both lvalues and rvalues:

std::string a, b, c;
// ...
foo(std::move(a));       // fine, a is an lvalue
foo(std::move(b + c));   // nonsense, b + c is already an rvalue

But since the whole point of std::move is to cast to an rvalue, why are we even allowed to std::move rvalues? Wouldn't it make more sense if std::move would only accept lvalues?

template<typename T>
T&&
move(T& t)
{
    return static_cast<T&&>(t);
}

Then the nonsensical expression std::move(b + c) would cause a compile-time error.

The above implementation of std::move would also be much easier to understand for beginners, because the code does exactly what it appears to do: It takes an lvalue and returns an rvalue. You don't have to understand universal references, reference collapsing and meta functions.

So why was std::move designed to take both lvalues and rvalues?

vsoftco
  • 55,410
  • 12
  • 139
  • 252
fredoverflow
  • 256,549
  • 94
  • 388
  • 662
  • My quick guess would be that when you write code to move things around you don't want to be constantly thinking whether your variables are lvalues or rvalues, you just want to do it. – sim642 Mar 09 '15 at 06:30
  • 3
    Because it is designed to cast both lvalue and rvalue to rvalue unconditionally. –  Mar 09 '15 at 06:31
  • @6502 This question or the details of it are more useful for a library developer than application developer. Application developer can just happily call std::move(); and get on with the work. Of course should understand that moving the local variable would make the state invalid. Otherwise nothing to break the head here. – Jagannath Mar 09 '15 at 06:37
  • @Jagannath: mine was just a rant about the very sad state of this C++ part. We simply got more possibilities for undefined behavior and complex semantic with special cases (and THAT is the problem of C++, not speed). – 6502 Mar 09 '15 at 06:40
  • 11
    @6502 And rants don't belong on stack overflow, wouldn't you agree? – fredoverflow Mar 09 '15 at 06:41
  • As I understand it, inside a template function that takes a "universal reference" you don't know whether it will bind to an r-value or an l-value so maybe that's why `std::move` needs to accept both. – Galik Mar 09 '15 at 07:00
  • 3
    In generic code sometimes you do not know if an expression is an lvalue or an rvalue (function calls, for instance), but may want to unconditionally move from it. Also, allowing the quasi-identity rvalue-to-rvalue cast isn't dangerous, so there isn't a compelling reason to prohibit it. But I suspect only Howard Hinnant knows the *real* reason... – T.C. Mar 09 '15 at 07:01
  • 4
    @Galik this is a bit of a misconception. When you apply `std::move(x)` inside some `template f(T&& x)`, then `x` is a lvalue of type rvalue reference (in case a rvalue was passed). So you actually apply `std::move` on a lvalue in this case. But I guess the problem appears when doing something like `std::move(f())`, and you may not know whether `f` returns a lvalue reference or a rvalue. – vsoftco Mar 09 '15 at 07:15
  • i guess because convenience!we don't worry about rvalue or lvalue or a lvalue of type ravalue reference..... – Ron Tang Mar 09 '15 at 07:26
  • @6502: I agree with you I am myself not yet familiar with these constructs but it seems C++ is adding more complexity into the language, whereas it was uneccessary – Giorgi Moniava Mar 09 '15 at 07:42
  • @Giorgi Unfortunately move semantics was quite necessary. If you think otherwise, ponder on `std::auto_ptr` and try to implement a working solution to that problem without move semantics. – juanchopanza Mar 09 '15 at 07:54
  • @juanchopanza: Playing devil's advocate here (I definitely don't agree with Giorgi and 6502's opinion). Don't allow copying or assigning at all of `auto_ptr`, and just give it a move member function which transfers ownership to another `auto_ptr`. Then you can move it out of a function via a reference parameter. Is that the problem you are referring to? – Benjamin Lindley Mar 09 '15 at 08:16
  • @juanchopanza: in language where you can trigger UB easily(?)-you should strive to minimize cases when that happens instead of introducing new features which can introduce UB (I agreed with 6502 only on this point, I don't even refer specifically to move semantics, I am not familiar with it). – Giorgi Moniava Mar 09 '15 at 08:28
  • @Giorgi I may be missing something, but I'm not sure how rvalue references introduce UB beyond what was already possible in C++03. I do agree that the language is overly complex, but unfortunately it isn't possible to get rid of "old" complexity that doesn't buy you much. I think the extra complexity in rvalue references is warranted. Obviously that is my personal opinion. – juanchopanza Mar 09 '15 at 08:36

2 Answers2

12

Here is some example simplified to the extreme:

#include <iostream>
#include <vector>

template<typename T>
T&& my_move(T& t)
{
    return static_cast<T&&>(t);
}

int main() 
{
    std::vector<bool> v{true};

    std::move(v[0]); // std::move on rvalue, OK
    my_move(v[0]);   // my_move on rvalue, OOPS
}

Cases like the one above may appear in generic code, for example when using containers which have specializations that return proxy objects (rvalues), and you may not know whether the client will be using the specialization or not, so you want unconditional support for move semantics.

Morwenn
  • 21,684
  • 12
  • 93
  • 152
vsoftco
  • 55,410
  • 12
  • 139
  • 252
4

It doesn't hurt.

You're simply establishing a guarantee that code will treat the result as an rvalue. You certainly could write std::move in such way that it errors out when dealing with something that's already an rvalue, but what is the benefit?

In generic code, where you don't necessarily know what type(s) you're going to be working with, what gains in expressiveness would you extract out of a bunch of "if type is rvalue do nothing else std::move" plastered everywhere when you can simply say "I promise we can think of this as an rvalue".

You said it yourself, it is nothing more than a cast. Should *_cast operations also fail if the argument already matches the intended type?

ZaldronGG
  • 924
  • 8
  • 13