Re: [boost] [outcome] How to drop the formal empty state

Subject: Re: [boost] [outcome] How to drop the formal empty state
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-05-26 23:36:54

>> As mentioned in another discussion thread, the empty state is also used
>> internally as a micro-optimisation. So it would likely remain internally
>> whatever the decision taken here, as a tool for making the CPU expend
>> identical CPU cycles on both positive and negative branches on state.
>>
>> Again, if people don't like that behaviour of outcome/result to be
>> equally costly on T or E branches chosen,
> 
> 
> What does it mean tha "outcome is equally costly on T or E branches chosen"?

Have a look at https://godbolt.org/g/bVd4D7, specifically the disassembly.

As you'll note, the first possible state (empty) tends to be chosen by
the compiler as the most likely. That implies a 20 cycle branch
misprediction cost for each of the valued or errored states. So they are
equally costly, which is intentional.

>> Resetting to empty looks attractive, but I found out the hard way it is
>> a bad design decision. Code consuming a rvalue reference does not
>> actually have to move anything, nothing in the C++ standard says it
>> does. It's only a widely held convention that it ought to.
>>
> 
> In optional<T> we deliberately don't put the moved-from object into an
> empty state (which surprises many people). This is for performance reasons:
> when `T` is a trivial type, `optional<T>` can be made trivially_copyable.

+1

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/