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 9 hours ago | parent | next [-]

"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).

▲

drysine 11 hours ago | parent | prev [-]

>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...

▲

knorker 9 hours ago | parent [-]

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 9 hours ago \| parent [-]
		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.