Re: [boost] Reforming Boost.System and <system_error> round 2

Subject: Re: [boost] Reforming Boost.System and <system_error> round 2
From: Peter Dimov (lists_at_[hidden])
Date: 2018-01-16 16:40:46

Andrzej Krzemienski wrote:
> 2018-01-16 17:05 GMT+01:00 Andrey Semashev via Boost 
> <boost_at_[hidden]>:
>
> > On 01/16/18 18:56, Olaf van der Spek via Boost wrote:
> >
> >> Can't the is_error bool be stored in the ec object itself, at 
> >> construction time?
> >>
> >
> > Actually, I like this idea. I've modified my benchmark accordingly and 
> > it shows nearly identical performance as the current `std::error_code`:
> >
> > Experimental test: 253654 usec, 394237820.022550 tests per second
> > Experimental2 test: 46353 usec, 2157357668.327832 tests per second
> > std test: 45981 usec, 2174811335.116679 tests per second
>
> This is now getting closer to Boost.outcome, isn't it?

It's a conforming implementation of the same (implied so far) specification. 
You have

    bool error_code::failed() const noexcept;

    Returns: category().failed( value() );
    Remarks: implementations are allowed to cache the result of the 
expression.

Now, it's up to the implementation whether it will decide to cache the 
result in a bool or not. On a typical 64 bit platform, you have four bytes 
of unused padding between the `int value_` and the `error_category const * 
cat_` so you can fit a bool there (or 32 bools) without any size overhead.

A 32 bit platform may choose to just do the virtual call each time instead.

It's true that if we use Outcome, the "failed" bit is already there so we 
don't need to ask the error_code at all. But the topic here, brought up by 
Niall, is error_code and not Outcome. Presumably, being the author of 
Outcome, he wouldn't ask for something he knows he doesn't need. :-)