Re: [boost] [outcome] Exception safety guarantees

Subject: Re: [boost] [outcome] Exception safety guarantees
From: Howard Hinnant (howard.hinnant_at_[hidden])
Date: 2017-05-30 14:48:13

On May 30, 2017, at 7:13 AM, Andrzej Krzemienski via Boost <boost_at_[hidden]> wrote:
> 
> 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).
>> 
>> 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.
>> 
>> 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.
>> 
>> 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.
>> 
> 
> Ok, I think I asked the wrong question. I asked:
> 
> what do the STL containers/algorithms do with the moved-from objects
>> 
> 
> But what I actually meant was:
> 
> "when an STL algorithm *causes* an object to obtain a valid-but-unspecified
> *during its operation* , what does it later do with this object other than
> to destroy it or re-set it (or leave it like this for the caller -- for the
> caller to destroy it or reset it)?"
> 
> Because, if I myself am passing objects in valid-but-unspecified state to
> STL algorithms, I am already doing something wrong (I should have probably
> destroyed or reset these objects).

I had interpreted your question the way you meant it.  My answer doesn’t change.

Howard