1

As I know std::move (same as static_cast<T&&>) casts variable to rvalue and assigns to lvalue, and because of this I think in following code:

int a = 1;
int b = static_cast<int&&>(a);

b and a have the same address, but in VS, it prints different addresses.

int a = 1;
int b = static_cast<int&&>(a);
cout << hex << &a << endl;
cout << hex << &b << endl;

If after this a still points to a different memory location, what is the benefit of using std::move in this case?

Jarod42
  • 203,559
  • 14
  • 181
  • 302

4 Answers4

8

Just because you "move" them doesn't mean they will share the same address. Moving a value is a high level abstraction, with basic types like int moving and copying is completely the same, which is happening here. I suggest you read the excellent post on std::move to know what it does and what it's uses are.

Hatted Rooster
  • 35,759
  • 6
  • 62
  • 122
2

No, b is its own object, which is copy initialized from an rvalue reference to another int. This is the same as just copying the referenced object.

Move semantics only shines when the "copying" can be preformed by resource stealing (since we know the other objects storage is about to go, anyway).

For a type like an integer, it's still a plain copy.

StoryTeller - Unslander Monica
  • 165,132
  • 21
  • 377
  • 458
0

When you use std::move in C++ you do not move the object itself, you move the value of the object or its contents. So its address does not change.

Moving is no different from copying with an int. But for a complex type with internal pointers to allocated memory, that memory can be transferred without copying using a std::move (assuming it has been designed to respond to std::move).

Galik
  • 47,303
  • 4
  • 80
  • 117
  • 2
    Isn't `std::move` just a `static_cast`, so it doesn't actually move anything by itself? – Rakete1111 Jun 20 '17 at 10:02
  • not sure why this was downvoted. Imho it helps to think of move as not moving the instance itself but its contents. The fact that `std::move` actually does not move anything is just a quirk of the language, but still most of the time when calling `std::move` one is actually moving something. – 463035818_is_not_an_ai Jun 20 '17 at 10:08
  • @Rakete1111 The language rules trigger a *move* operation if you make that cast (move construct or assign). So the way you *move* things in `C++` is to use the expression `std::move`. So no, `std::move` does not actually move anything by itself but the compiler does when you use `std::move` (assuming you use it on an object designed to be moved). – Galik Jun 20 '17 at 10:08
  • 1
    @Galik The language doesn't trigger a "move operation". The library implementor does. – juanchopanza Jun 20 '17 at 10:19
  • @juanchopanza Respectfully disagree. The library implementer presents the compiler with the facility to either move or copy, the compiler decides which facility to employ based on language rules and the programmer forces the compiler to choose move by using the cast `std::move`. – Galik Jun 20 '17 at 10:22
  • The language doesn't have any "move operation". – juanchopanza Jun 20 '17 at 10:23
  • @juanchopanza I don't believe I said it did. I said it *triggers* a move operation which the library designer may or may not have facilitated. – Galik Jun 20 '17 at 10:24
0

There is no benefit of using std::move on an int. In your example you are basically copying the value from a to b.

Move semantics is only meaningfull on resources where you want to transfer ownership, e.g. dynamically allocated memory. Take the std::unique_ptr as an example.

auto ptr = std::make_unique<int>(1);
auto ptrCopy = ptr;     // copy will not work compilation error.       
auto ptrMove = std::move(ptr);

In the above example ptrMove has taken over the ownership of ptr and ptr is now empty.

0xBADF00
  • 1,028
  • 12
  • 26
  • Not just memory. All resources can be meaningfully moved. Open files, connections, unique_locks, opaque handles … – spectras Jun 20 '17 at 10:31