0

While reading some articles about the std::move semantics and the rvalue references, I came to know that they were introduced because copying data is an expensive job. True ! Copying is expensive but isn't that the same reason why we have "REFERENCES" in C++. They also just help pass the address of a variable and prevent the expensive procedure of copying.

Then why have std::move and rvalue been introduced ? I mean what job couldn't normal references do which the former ones could do ?

My question extends mainly to functions. I mean when you pass a variable to a function, which is better & why ? :- 1. Pass by lvalue reference 2. Pass by rvalue reference using move

Anwesha
  • 728
  • 1
  • 7
  • 18
  • 4
    One example would be returning an object from a function. – declapp auto Jun 22 '15 at 17:57
  • references too do the same, dont they ? – Anwesha Jun 22 '15 at 17:59
  • 1
    They are not. How can you return local object by reference? std::move and move semantic is power for template metaprogramming. – gomons Jun 22 '15 at 18:01
  • It facilitates semantics for exchange of ownership and unique ownership (i.e `std::unique_ptr` and `std::thread` wouldn't be quite intuitive if there were no built in move semantics). – David G Jun 22 '15 at 18:06
  • my question is about std::move and rvalue refernces together sir @ 0x499602D2 not only abt std::move – Anwesha Jun 22 '15 at 18:08
  • This post might be useful http://stackoverflow.com/a/5481588/2352158. You can see that you have cases where you avoid copying which would not be possible with "normal ref" – coincoin Jun 22 '15 at 18:08
  • 1
    This is a really broad question. [This Q&A](https://stackoverflow.com/q/3106110/241631) does a pretty good job of explaining move semantics. I recommend reading a C++ textbook that covers C++11 for further understanding. And `std::move` doesn't really move anything, it prepares an object so that it can subsequently be moved from. @gomons *std::move and move semantic is power for template metaprogramming* ... care to elaborate on that? – Praetorian Jun 22 '15 at 18:10
  • Moving is not faster than passing by reference or pointer. However, moving is almost always faster than copying so, where moving would have the same effect of copying, it's free job to get rid of. – edmz Jun 22 '15 at 18:23

1 Answers1

6

Move semantics is there for situations when you have to copy data, i.e. when there's no way around it. The data has to "appear" in a new location, in a new object. I.e by design, the physical relocation/re-creation of data absolutely has to take place. Normal references don't cover this in any way. For example, when you add an element to a std::vector the element's value supplied by you also has to be appear in the new vector's element somehow.

Most of the time in classic C++ this was achieved by unconditionally copying data to the new location. However, it was rather obvious that in some cases we didn't really care about the fate of the original object, from which that data was copied - the original object was destroyed immediately after copying anyway. Naturally, it presented a rather obvious and huge optimization opportunity: since we didn't care about the original object, we could simply "steal" (move) data from it, place that data into the new location and then destroy the (now empty) original. This is significantly more efficient that meticulously "cloning" (copying) the data and destroying the original.

We used to take advantage of this optimization opportunity even in classic C++. But we had to do it manually, without support from the core language. Move semantics and rvalue references is how this support was introduced into the core language, this opening this optimization opportunity to the compiler itself.

In other words, move semantics does not "eliminate copying". It optimizes copying by taking advantage of the fact that the sequence

  1. Copy "heavy" src to dst
  2. Destroy "heavy" src

can be equivalently replaced by a much more efficient sequence

  1. Move "heavy" src do dst, making src "empty"
  2. Destroy "empty" src
AnT stands with Russia
  • 312,472
  • 42
  • 525
  • 765