user673679

Consider: a) destructors always get called in move-assignment: godbolt.org/z/e17of5c8h b) lifetimes leaked out of scope: godbolt.org/z/jxvxnfeoz

"where the programmer expects clean-up to be happening: scope exit." <-- Exactly! If you just swap in move assignment without doing cleanup, you can leak the lifetime OUT of the scope!

Nope. That's just wrong. It's just not how RAII and object lifetimes work. As stated: If you want swap, use swap. Move isn't swap - it ends the contained object lifetime (every container and object handle works this way). If memory can be reused, fine; but that's a whole different kettle of fish. It's a pessimization to swap in move-assignmet. It's more complicated to swap in move-assignment. It's bug-prone to swap in move-assignment.

@Caleth But not when the user wants or expects. If they want to do a swap... they can call std::swap. Move has different semantics.

Nah. I think we might be using the word "resource" differently. By resource, I mean an object or object handle wrapped by the class in question (i.e. RAII). That might be a file, socket, etc. The semantic lifetime of that object is very important because it often has side-effects. The issue I'm highlighting is what happens to the resource that used to be in the "moved-to" object. (Exactly what I said, I think!). Memory reuse is an optimization that might or might not be sensible. It doesn't matter. Files write on close!!!! They write on close!!!

I wouldn't call POD types resources. A vector calls the destructor on any contained objects if you copy assign to it. A file handle (stream) will not keep the file open when you move to it. In the case of resource handles, it's pretty much universal to free or close or destroy the resource when moving to an object. "In any real-world code, a moved-from object is about to be destroyed or reassigned", but then it's "a good idea [because] you already have the memory"??? Memory reuse has nothing to do with ensuring well-defined and simple resource lifetimes.

"When a type is not specified to release its resources on being moved from, it’s up to the type authors". You mean the "moved-to" object?

@AdamBarnes Copy assignment frees the existing resource too, it doesn't just leak it.

I think it's pretty realistic. I've done it myself with socket handles for network code. I think it's very normal to want that resource freed "definitely now", and not "maybe sometime later". And for the user to know that the "moved from" handle is in a valid empty state is very useful. std::unique_ptr does exactly that.

In what way? The moved-from object still exists until the destructor is called some arbitrary time later. The resource that object used to contain lives on in the moved-to object. We want a definite bound on the lifetime of the resource formerly in the moved-to object (i.e. it dies now, not at some arbitrary time in the future).

Acceptable as in "moved from objects may be technically in an unspecified state" maybe. Acceptable as in "practical"? Absolutely not. It's not ok to presume that the moved from objects life is about to end. It's not ok to give the user the hassle of keeping a separate boolean around to see if a moved from handle is still active. It's not ok to give the user any confusion over what their handle "points to".

@Duga re-rolled and added another comment.

@Duga "But the question did not actually belong in code review at all." -- Narrator

How does encryptedRequest end up in cryptoService.decryptRequest() in that first code listing?

Work it into the story like this: shadowunit.org/readingorder.html