Comment by shmerl

19 hours ago

I always understood move as moving ownership, so it's not a misnomer.

> std::move is like putting a sign on your object “I’m done with this, you can take its stuff.”

Which exactly is moving ownership.

49 comments

shmerl

Reply
tsimionescu  17 hours ago

std::move itself doesn't move ownership, though. It allows the compiler to transfer ownership to the receiver of the value, but it doesn't force it in any way. This is important, because it means YOU may still be the owner of a value even after you called std::move on it.

Not to mention, ownership in C++ is not entirely lost with moves in the traditional sense. For example, your code still has to destruct the object even if you did move it to somewhere else.

vlovich123  18 hours ago

Std move doesn’t move ownership. It simply casts into something that could have its ownership taken. Whether or not that actually happens is impossible to identify statically and the value after ownership is consumed is unspecified - sometimes it’s UB to access the value again, sometimes it’s not.

  • mgaunard  18 hours ago

    That's quite inaccurate.

    It needs to remain destructible, and if the type satisfies things like (move-)assignable/copyable, those still need to work as well.

    For boxed types, it's likely to set them into some null state, in which case dereferencing them might be ill-formed, but it's a state that is valid for those types anyway.

    • vlovich123  12 hours ago

      Well it’s unspecified what empty/size return for collections after a move. Not a dereference, not UB but unspecified as I said. UB pops up in hand written code - I’ve seen it and the language doesn’t provide any protection here.

      Thankfully clippy lints do exist here to help if you integrate that tooling

  • shmerl  18 hours ago

    May be disown would be more descriptive, but the point is that it's intended for transferring of ownership versus copying data.

    • masklinn  17 hours ago

      > it's intended for transferring of ownership versus copying data.

      It's intended for transferring ownership, but what it actually does is mark the value as transferrable, whether or not the value is actually transferred is up to the callee.

  • knorker  16 hours ago

    After moving a value, it needs to remain in a "valid but unspecified state".

    How do you mean accessing a valid object is UB?

    • masklinn  14 hours ago

      "Validity" is an extremely low bar in C++, it just means operations with no preconditions are legal, which in the most general case may be limited to destruction (because non-destructive moves means destruction must always be possible).

  • tsimionescu  17 hours ago

    It is absolutely knowable statically if ownership will be taken. It's not necessarily very easy to do so, but the decision is 100% up to the compiler, as part of overload resolution and optimization choices (like the NRVO analysis that the article mentions). Since ownership is an inherently static concept, it doesn't even make sense to think about "runtime ownership".

HarHarVeryFunny  13 hours ago

Well, no, because CAN take isn't the same as WILL take.

Changing something to an rvalue means it'll now match a move constructor, but there is no guarantee a move constructor will be used, even if defined, because you've got classes like std::vector that are picky and are explicitly looking for a noexcept move constructor.

  • fluoridation  12 hours ago

    In that sense, std::move() is no different than other passing semantics. Just because you wrote at the call site that you want to pass a copy of your object doesn't mean that the callee will actually make a copy of it.

    • HarHarVeryFunny  11 hours ago

      I'm not sure what you are saying.

      If we have foo(std::string a, std string b), and then call it like this:

      std::string x;

      std::string y;

      foo(std::move(x), y);

      Then x will be moved into a, and y will be copied into b.

      The callee has no say in this - it's just the compiler implementing the semantics of the language.

      7 replies →

cocoto  18 hours ago

Personally I see std::move more like removing ownership because it’s not explicit from its call where the ownership is transferred.

  • tsimionescu  17 hours ago

    Even that is a bit suspect, because ownership may well remain with you even after the call, so it's not really removed.

    For example, this is perfectly valid C++, and it is guaranteed to have no issue:

      std::string abc = "abc";
  std::move(abc); //doesn't remove ownership or do anything really
  std::print(abc); //guaranteed to print "abc"