Move Constructor Beginner Question

[quick vapor]

I have a question regarding the example code found in cppref (https://en.cppreference.com/w/cpp/container/vector/emplace_back.html). I'm wondering about the move constructor of the President type; aren't you supposed to assign each member of the r-value ref to be empty? Why do they avoid that here?

[heady prism]

When your question is answered use !solved or the button below to mark the question as resolved.

Remember to ask specific questions, provide necessary details, and reduce your question to its simplest form. For tips on how to ask a good question use !howto ask.

[quick vapor]

Move Constructor Beginner Question

[whole granite]

do you mean year?

[quick vapor]

President(President&& other)
        : name(std::move(other.name)), country(std::move(other.country)), year(other.year)
    {
        std::cout << "I am being moved.\n";
    }

[whole granite]

for such trivial types move construction and copy construction are the same

[quick vapor]

Isn't it better practice to assign the members to something empty though?

Or does it really not matter

ohhh wait I think I see why

is it the std::move?

[whole granite]

I suppose the expectation is that after moving, the moved-from object is "soon" destroyed or "reset" before reuse

[quick vapor]

I wonder if the std::move on each member does effectively what I'm talking about

[mild widget]

Why would you assign something empty? That's just wasted performance. Also not all types have an empty state, int for example.

[whole granite]

for int year, both year(other.year) and year(std::move(other.year)) are the exact same

[quick vapor]

ah

[whole granite]

you could do year(std::exchange(year, 0)) if you wish to set it to some "empty" value

[mild widget]

It doesn't, at least not always. There are strings. If the string is short (typically 23 bytes or less) then the original string stays untouched after the move.

[indigo dome]

The premise is wrong, where do did you hear that?

[quick vapor]

maybe I just inferred it from a C++ book I'm reading

I haven't seen a move constructor not set the rvalue ref to have empty members

[indigo dome]

There are some types which must be "empty" after a move to get the correct semantics (e.g. think of unique_ptr which can't hold a pointer after being moved from to preserve the unique ownerhip semantics), but in general that is not the case and it is unnecessary work to zero or reset or empty anything.

[indigo dome]

that's only because they chose to use a raw pointer instead of unique_ptr to hold the allocation

[quick vapor]

Maybe it's the author just trying to help push the idea along

[indigo dome]

so they need to assure correct ownership semantics of the pointer manually

in most cases the move constructor can just be implicitly defined (rule-of-zero) and then it behaves like shown in the cppreference page

it just moves each member from the source to the target one by one and doesn't do anything else

they put the definition there only so that they could augment it with the std::cout statement for demonstration purposes

[mild widget]

No, it's required here. a must be left in a valid state. ~Vector() will delete elem;. If you don't do a.elem = nullptr; then it will break the current vector because it's now holding an invalid pointer.

[quick vapor]

okay so if you're implementing RAII with raw pointers then it should be used?

[mild widget]

Must be used

[indigo dome]

in general if you are writing a move constructor because your class holds a raw resource that requires custom cleanup (e.g. a raw pointer to a memory allocation), then you need to set something to zero/empty state to avoid double cleanup of the resource

the other use case for a move constructor is to optimize performance over some copy constructor, in that case it is not always necessary to zero/empty something in the source

[quick vapor]

Okay, thanks a lot guys