Re: [boost] [outcome] Exception safety guarantees

Subject: Re: [boost] [outcome] Exception safety guarantees
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2017-05-29 07:36:25

2017-05-29 6:15 GMT+02:00 Howard Hinnant via Boost <boost_at_[hidden]>:

> On May 28, 2017, at 6:36 PM, Andrzej Krzemienski via Boost <
> boost_at_[hidden]> wrote:
> >
> > 2017-05-28 2:10 GMT+02:00 Peter Dimov via Boost <boost_at_[hidden]>:
> >
> >>
> >> (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;