9 ms·

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 ident

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.

shmerl 10mo ago
May be disown would be more descriptive, but the point is that it's intended for transferring of ownership versus copying data.
- masklinn 10mo 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.
mgaunard 10mo 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 10mo 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
tsimionescu 10mo 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".
- adrianN 10mo ago
  My function can choose to move or not to move from an object based on io input.
  - tsimionescu 10mo ago
    Can you show an example of what you mean? My claim is that, if I call `foo(std::move(myObj))`, it is statically knowable if `foo` receives a copy of `myObj` or whether it is moved to it. Of course, `foo` can choose to further copy or move the data it receives, but it can't choose later on if it's copied or not. Now, if I give `foo` a pointer to myObj, it could of course choose to copy or move from it later and based on runtime info - but this is not the discussion we are having, and `std::move` is not involved from my side at all.
    - masklinn 10mo ago
      > Can you show an example of what you mean? void foo(std::unique_ptr<int, Deleter>&& p) { std::random_device rdev {}; auto dist = std::uniform_int_distribution<>(0, 1); if (dist(rdev)) { auto pp = std::move(p); } }
      - tsimionescu 10mo ago
        This is exactly what I meant as irrelevant. If I call `foo(std::move(my_unique_ptr))`, I know for sure, statically, that my_unique_ptr was moved from, as part of the function call process, and I can no longer access it. Whether `foo` chooses to further move from it is irrelevant.
knorker 10mo 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?
- drysine 10mo ago
  >After moving a value, it needs to remain in a "valid but unspecified state". No, it doesn't. The standard library requires that for its classes, but not the language. "Unless otherwise specified, such moved-from objects shall be placed in a valid but unspecified state."[0] [0] https://timsong-cpp.github.io/cppwp/n4950/lib.types.movedfrom#1 https://timsong-cpp.github.io/cppwp/n4950/lib.types.movedfro...
  - knorker 10mo ago
    Ok, fair enough. So you're saying if you use the language to write UB, then you get UB? Seems kinda circular. Ok, you're not the same user who said it can be UB. But what does it then mean to same "sometimes it's UB" if the code is all on the user side? "Sometimes code is UB" goes for all user written code.
    - drysine 10mo ago
      I mean the language doesn't dictate what post-condition your class has for move-ctor or move-assignment. It could be - "don't touch this object after move" (and it's UB if you do) or - "after move the object is in valid but unspecified state" (and you can safely call only a method without precondition) or - "after move the object is in certain state" - or even crazy "make sure the object doesn't get destroyed after move" (it's UB if you call delete after move or the object was created on the stack and moved from). But of course it's a good practice to mimic the standard library's contract, first of all for the sake of uniformity.
- masklinn 10mo 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).

shmerl 10mo ago

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

masklinn 10mo 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.

mgaunard 10mo 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 10mo 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

tsimionescu 10mo 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".

adrianN 10mo ago
My function can choose to move or not to move from an object based on io input.
- tsimionescu 10mo ago
  Can you show an example of what you mean? My claim is that, if I call `foo(std::move(myObj))`, it is statically knowable if `foo` receives a copy of `myObj` or whether it is moved to it. Of course, `foo` can choose to further copy or move the data it receives, but it can't choose later on if it's copied or not. Now, if I give `foo` a pointer to myObj, it could of course choose to copy or move from it later and based on runtime info - but this is not the discussion we are having, and `std::move` is not involved from my side at all.
  - masklinn 10mo ago
    > Can you show an example of what you mean? void foo(std::unique_ptr<int, Deleter>&& p) { std::random_device rdev {}; auto dist = std::uniform_int_distribution<>(0, 1); if (dist(rdev)) { auto pp = std::move(p); } }
    - tsimionescu 10mo ago
      This is exactly what I meant as irrelevant. If I call `foo(std::move(my_unique_ptr))`, I know for sure, statically, that my_unique_ptr was moved from, as part of the function call process, and I can no longer access it. Whether `foo` chooses to further move from it is irrelevant.

knorker 10mo 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?

drysine 10mo ago
>After moving a value, it needs to remain in a "valid but unspecified state". No, it doesn't. The standard library requires that for its classes, but not the language. "Unless otherwise specified, such moved-from objects shall be placed in a valid but unspecified state."[0] [0] https://timsong-cpp.github.io/cppwp/n4950/lib.types.movedfrom#1 https://timsong-cpp.github.io/cppwp/n4950/lib.types.movedfro...
- knorker 10mo ago
  Ok, fair enough. So you're saying if you use the language to write UB, then you get UB? Seems kinda circular. Ok, you're not the same user who said it can be UB. But what does it then mean to same "sometimes it's UB" if the code is all on the user side? "Sometimes code is UB" goes for all user written code.
  - drysine 10mo ago
    I mean the language doesn't dictate what post-condition your class has for move-ctor or move-assignment. It could be - "don't touch this object after move" (and it's UB if you do) or - "after move the object is in valid but unspecified state" (and you can safely call only a method without precondition) or - "after move the object is in certain state" - or even crazy "make sure the object doesn't get destroyed after move" (it's UB if you call delete after move or the object was created on the stack and moved from). But of course it's a good practice to mimic the standard library's contract, first of all for the sake of uniformity.
masklinn 10mo 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).