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?

Improve this question
3
  • 12
    a and b are distinct objects, so they cannot have the same address. That has nothing to do with std::move. Commented Jun 20, 2017 at 9:40
  • 11
    And yes, it always works as expected, if your expectations are correct :-) Commented Jun 20, 2017 at 9:44
  • But static_cast<T&&> is std::forward<T> Commented Jun 20, 2017 at 10:54

4 Answers 4

Reset to default
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.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

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.

Improve this answer

Comments

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.

Improve this answer

1 Comment

Not just memory. All resources can be meaningfully moved. Open files, connections, unique_locks, opaque handles …
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).

Improve this answer

7 Comments

Isn't std::move just a static_cast, so it doesn't actually move anything by itself?
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.
@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 The language doesn't trigger a "move operation". The library implementor does.
@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.
|