Sunday, November 11, 2012

On the Superfluousness of std::move

During my presentation of "Universal References in C++11" at C++ and Beyond 2012, I gave the advice to apply std::move to rvalue reference parameters and std::forward to universal reference parameters.  In this post, I'll follow the convention I introduced in that talk of using RRef for "rvalue reference" and URef for "universal reference."

Shortly after I gave the advice mentioned above, an attendee asked what would happen if std::forward were applied to an RRef instead of std::move.  The question took me by surprise.  I was so accustomed to the RRef-implies-std::move and URef-implies-std::forward convention, I had not thought through the implications of other possibilities.  The answer I offered was that I wasn't sure what would happen, but I didn't really care, because even if using std::forward with an RRef would work, it would be unidiomatic and hence potentially confusing to readers of the code.

The question has since been repeated on stackoverflow, and I've also received it from attendees of other recent presentations I've given.  It's apparently one of those obvious questions I simply hadn't considered.  It's time I did.

std::move unconditionally casts its argument to an rvalue.  Its implementation is far from transparent, but the pseudocode is simple:
  
  // pseudocode for for std::move
  template<typename T>
  T&& std::move(T&& obj)
  { 
    return (T&&)obj;        // return obj as an rvalue
  }
std::forward is different.  It casts its argument, which is assumed to be a reference to a deduced type, to an rvalue only if the object to which the reference is bound is an rvalue. (Yes, that's a mouthful, but that's what std::forward does.)  Whether the object to which the reference is bound is an rvalue is determined by the deduced type.  If the deduced type is a reference, the referred-to object is an lvalue.  If the deduced type is a non-reference, the referred-to object is an rvalue.  (This explanation assumes a lot of background on how type deduction works for universal reference parameters, but that's covered in the talk as well as in its printed manifestations in Overload and at ISOcpp.org.)

As with std::move, std::forward's implementation is rather opaque, but the pseudocode isn't too bad:
  // pseudocode for for std::forward
  template<typename T>
  T&& std::forward(T&& obj)
  { 
    if (T is a reference)
      return (T&)obj;          // return obj as an lvalue 
    else
      return (T&&)obj;        // return obj as an rvalue 
  }
Even the pseudocode makes sense only when you understand that (1) if T is a reference, it will be an lvalue reference and (2) thanks to reference collapsing, std:forward's return type will turn into T& when T is an lvalue reference.  Again, this is covered in the talk and elsewhere.

Now we can answer the question of what would happen if you used std::forward on an RRef.  Consider a class Widget that offers a move constructor and that contains a std::string data member:
  class Widget {
  public:
    Widget(Widget&& rhs);       // move constructor
  
  private:
    std::string s;
  };
The way you're supposed to implement the move constructor is:
  Widget::Widget(Widget&& rhs)
  : s(std::move(rhs.s))
  {}
Per convention, std::move is applied to the RRef rhs when initializing the std:string.  If we used std::forward, the code would look like this:
  Widget::Widget(Widget&& rhs)
  : s(std::forward<std::string>(rhs.s)
  {}
You can't see it in the pseudocode for std::forward, but even though it's a function template, the functions it generates don't do type deduction.  Preventing such type deduction is one of the things that make std::forward's implementation less than transparent.  Because there is no type deduction with std::forward, the type argument T must be specified in the call.  In contrast, std::move does do type deduction, and that's why in the Widget move constructor, we say "std::move(rhs.s)", but "std::forward<std::string>(rhs.s)".

In the call "std::forward<std::string>(rhs.s)", the type std::string is a non-reference. As a result, std::forward returns its argument as an rvalue, which is exactly what std::move does.  That answers the original question.  If you apply std::forward to an rvalue reference instead of std::move, you get the same result. std::forward on an rvalue reference does the same thing as std::move.

Now, to be fully accurate, this assumes that you follow the rules and pass to std::forward the type of the RRef without its reference-qualifiers.  In the Widget constructor, for example, my analysis assumes that you pass std::forward<std::string>(rhs.s).  If you decide to be a rebel and write the call like this,
  std::forward<std::string&>(rhs.s)
rhs.s would be returned as an lvalue, which is not what std::move does. It also means that the std::string data member in Widget would be copy-initializd instead of move-initialized, which would defeat the purpose of writing a move constructor.

If you decide to be a smart aleck and write this,
  std::forward<std::string&&>(rhs.s)

the reference-collapsing rules will see that you get the same behavior as std::move, but with any luck, your team lead will shift you to development in straight C, where you'll have to content yourself with writing bizarre macros.

Oh, and if you make the mistake of writing the move constructor like this,
  Widget::Widget(Widget&& rhs)
  : s(std::forward<Widget>(rhs.s))
  {}
which, because I'm so used to passing std::forward the type of the function parameter, is what I did when I initially wrote this article,  you'll be casting one type (in this case, a std::string) to some other unrelated type (here, a Widget), and I can only hope the code won't compile.  I find the idea so upsetting, I'm not even going to submit it to a compiler.

Summary time:
  • If you use std::forward with an RRef instead of std::move, and if you pass the correct type to std::forward, the behavior will be the same as std::move.  In this sense, std::move is superfluous.
  • If you use std::forward instead of std::move, you have to pass a type, which opens the door to errors not possible with std::move.
  • Using std::forward requires more typing than std::move and yields source code with more syntactic noise.
  • Using std::forward on an RRef is contrary to established C++11 idiom and contrary to the design of move semantics and perfect forwarding.  It can work, sure, but it's still an anathema.
Scott

21 comments:

Zahir said...

Do you have any idea about why these functions are 'functions' but not language keywords or a keyword like 'sizeof(param)'? I'd like it working without type deduction and only using the type on the declaration (without reference ofcourse) for which we should use forward for, otherwise it seems like a bug breeder.

Rein Halbersma said...

Seinfeld (seaon 2, episode 6)

George: Students can't clean. It's anathema. (explaining) They don't like it.

Jerry: How long have you been waiting to squeeze that into a conversation?

Anonymous said...

The last code sample is missing a close paren for the initializer.

Nacho said...

You have a typo on the second code paragraph. Now guess....

No, really, it's the second return.

Joseph Mansfield said...

I'm the asker of the question on StackOverflow. Thanks for the response, Scott!

Scott Meyers said...

@Zahir: As a general rule, the standardization committee prefers to implement features in the library instead of in the core language. I assume that because std::move and std::forward can be implemented as library functions, the committee saw no reason to modify the language proper.

Scott Meyers said...

@Anonymous and @Nacho: Thanks for the typo bug reports. Both are now fixed.

Leszek Swirski said...

As I understand it, std::move is a special case of std::forward, which passes std::remove_reference::type&& as the type parameter of T to force it to be an rvalue reference, rather than relying on the reference collapsing rules (the "scary truth") to make the right choice. Is this right?

Btw, if you want a more minor bug report, one tends to just say "anathema" as opposed to "an anathema" [Source].

Scott Meyers said...

@Leszek Swirski: As I wrote in the article, std::move is an unconditional cast to an rvalue, so it takes steps to ensure that reference collapsing does not yield an lvalue reference as a a return type. I would not say that std::move is a special case of std::forward, because they are designed to be called using different syntax and to accomplish different things. There are various ways to implement these functions, and I suppose that std::move could even be implemented in terms of std::forward, but I've never heard of this being done.

Dave Abrahams said...

move() and forward<>() may look similar at a low level, but semantically are really completely separate ideas. You might be able to implement one in terms of the other, but there's a very good reason that the standard provides both.

You use move(x) when you know you want to move from x, because it is a value that is no longer needed for anything else. Think of this, at a high level, as enabling an optimization of copy.

You use forward(x) when you don't know whether x is bound to an rvalue or lvalue in your caller, so its value might be needed even after you return. Think of this, at a high-level, as ressurecting any rvalue-ness that may have been erased by giving the argument a name.

Anonymous said...

Can you explain (for someone who's not very bright) why writing




std::forward<std::string&&>(rhs.s)




would be reason to get kicked out of the C++ club? I feel like it's going to be a while before all this rvalue-ref stuff really sinks in for me.

Oh, and there's still one missing paren (in the example just following the "Per convention..." line).

Scott Meyers said...

@Anonymous: The reason why std::forward<string&&> is strange is that the template argument for std::forward is expected to be a deduced parameter type, and deduced parameter types are lvalue references for lvalues and non-references for rvalues. Because std::string&& is neither of these, it looks odd. I can't think of any way in which it would behave differently from std::string (i.e., a non-reference) inside std::forward, so I think the net effect of passing std::string&& would be the same as passing std::string, but I'm not sure, and it certainly runs contrary to convention.

BTW, the rvalue-ref stuff is still sinking in for me, too, and I've been trying to figure it out for about three years :-)

Howard Hinnant said...

std::forward<T&&>(t) is exactly the same as std::forward<T>(t), whether or not T is an lvalue reference. The only difference is that the former is syntactically noisier.

Mohammad said...

Hello Mr. Scott Meyers
I encounter a problem in reading your book. Would you please help me!
I don't know where should i ask it so I post it in StackOwerflow.
Thank you!

http://stackoverflow.com/questions/13660451/public-inheritance-and-mixin-style

Anonymous said...

Hi Scott! I love your talks and articles! I have one question. Say some function returns a temporary Widget and the move constructor of Widget is called:

Widget::Widget(Widget&& rhs)
: s(std::forward(rhs.s)
{}

As I understood it, inside the move constructor, rhs has a name and I can take its address as well as the address of rhs.s, so I would expect it to be an lvalue reference. That is, I would expect std::forward to do the right thing and return an lvalue reference too. I thought the point of using std::move(rhs.s) there was to force the call to the move constructor of string, something that std::forward would not do.

I guess I got it completely wrong :s

Scott Meyers said...

@Anonymous: You're correct that rhs is an lvalue, and you'd be right that std::forward would return an lvalue reference if called with rhs.s, but you have to pass std::forward a type argument, so the code you wrote would not compile.

Scott

Scott Meyers said...

@Mohammad: First, I apologize for the long delay. I overlooked your comment.

As for your question itself, I agree that having Widget inherit from NewHandlerSupport<Widget> does not correspond to the classic notion of "is-a," but Item 32 remarks that the use of public inheritance asserts that, given a base class B and a publicly derived class D, "anywhere an object of type B can be used, an object of type D can be used just as well, because every object of type D is an
object of type B." In this case, it's true that a Widget can be used anywhere a NewHandlerSupport<Widget> can, so the "is-a" requirement is satisfied. (The technical requirement is substitutability: publicly derived classes must be substitutable for base classes. In Item 49, that's the case: you can substitute a Widget for a NewHandlerSupport<Widget>, and your code will continue to work.)

Anonymous said...

It seems that blogger ate all my square brackets... sorry for that! This is what I wrote

Widget::Widget(Widget&& rhs)
: s(std::forward < std::string > (rhs.s))
{}

If you leave the spaces between the brackets the type just disappears, reminds me of c++03 and >> :D

Anders Sjögren said...

My understanding is that std::move and std::forward typically explicitly express the last use of a variable in a function, where move is used if the variable is created or taken by value in the function, where forward if it is taken as universal reference.

Since the compiler can infer the last use and the origin of the variable, why not let the compiler entirely automate the move/forward business? In other words: What prevents the compiler from figuring out the last use of each variable and automatically inserting the equivalent of move and forward at that location?

Scott Meyers said...

@Anders Sjögren: This is an interesting question, and I don't know if there is a technical justification for the restriction. It's perhaps worth noting that some lvalues are already implicitly treated as rvalues, notably variables thrown as exceptions and variables used as return expressions, so there are already parts of the language where the behavior you advocate takes place. I encourage you to post this question to StackOverflow. Howard Hinnant is active there, so you'd have a good chance to get an answer from the guy who is largely responsible for the design of rvalue references.

Scott

Mohammad said...

Thank you very much Mr.Scott Meyers.