Boost logo

Boost :

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, 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.



ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at