Comment by 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.
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.
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
May be disown would be more descriptive, but the point is that it's intended for transferring of ownership versus copying data.
> 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.
After moving a value, it needs to remain in a "valid but unspecified state".
How do you mean accessing a valid object is UB?
"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).
>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.movedfro...
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.
1 reply →
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".
My function can choose to move or not to move from an object based on io input.
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.
17 replies →
I don't understand the downvoted here. Either the compiler emits the code to call a move constructor or it doesn't.
Static analysis is about proving whether the code emitted by a compiler is actually called at runtime. It's not simply about the presence of that code.
Code can be emitted but never executed.
3 replies →