Re: [boost] [outcome] Exception safety guarantees

2017-05-29 6:15 GMT+02:00 Howard Hinnant via Boost :

On May 28, 2017, at 6:36 PM, Andrzej Krzemienski via Boost < boost@lists.boost.org> wrote:

...

2017-05-28 2:10 GMT+02:00 Peter Dimov via Boost :

...

(It's the same for move, by the way. There are people who prefer destroy-only for moved-from objects. The standard library does not agree with them, this time because Howard.)

Acknowledged. But what do the STL containers/algorithms do with the moved-from objects other than to destroy them or reset them?

They are allowed to do everything with moved-from objects that they are allowed to do with objects that haven’t been moved from. For example sort is allowed to move construct from, move assign to, move assign from, swap, and compare objects, whether or not they are in a moved from state. std::sort requires objects to satisfy strict weak ordering. This means among other things that x < x is always false, even if x is in a moved-from state.

In summary, being in a moved-from state does not excuse an object from meeting the requirements of the algorithm it is being used with. It only excuses the object from having a specified state (in most cases).

Thanks. that was useful.

Real-world examples:

An old std::reverse implementation, when given a range with an odd length, would swap the middle element with itself. This results in a moved-from object being self-move-assigned if the generic std::swap is being used. It just has to work. By work, I mean that the self-move-assignment of a moved-from-object has to leave the object in a valid but unspecified state. If it does this, then self-swap is a non-modifying operation, and the reverse algorithm gives the correct result.

Ok, self-assignment is something different than only "being able to assign to". But that could be added to the minimum safety requirements.

The std::remove algorithm returns moved-from objects back to the client (those at the end of the sequence that have been “removed”). The client is free to do anything he wants with those objects as long as that operation does not have a precondition. Although the typical use case is for the client to delete those “removed” elements, that is by no means required, or the only use case.

Ok, so who of the people who are following this thread ever did anything else with these past-removal objects, other than to destroy them? I am not being sarcastic. I just can't imagine anyone doing anything else with them.

I know of no sort implementation that compares moved-from objects (though I have not done a rigorous survey either). But it is quite possible that a sort algorithm could compare a moved-from object against itself, and still be a correct algorithm, as long as x < x (or comp(x, x)) _always_ returns false.

Variant's semantics meet these requirements, even in valueless_by_exception state. Right? Thanks, &rzej;