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

Subject: Re: [boost] Reforming Boost.System and <system_error> round 2
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2018-01-16 16:57:46

On 01/16/18 19:40, Peter Dimov via Boost wrote:
> 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.

For the record, I was thinking of (and testing) a different 
implementation that does not involve the `failed` call. Instead, I 
changed the `error_code` constructors:

   class error_code
   {
     int _value;
     bool _is_failure;
     const experimental::error_category *_category;
   public:
     constexpr error_code(int v, const experimental::error_category &cat)
       : _value(v), _is_failure(v != 0), _category(&cat) {}
     constexpr error_code(int v, bool is_failure,
        const experimental::error_category &cat)
       : _value(v), _is_failure(is_failure), _category(&cat) {}

     // Fixed operator bool, now asks category
     explicit operator bool() const noexcept
     {
       return _is_failure;
     }
   };

Calling (virtual) `error_category::failure` early is a waste if the user 
doesn't want to call that function himself. For instance, he may want to 
test specific error codes instead.

Caching the result of `error_category::failure` on demand seems useless 
because most likely the error code will be tested for success only once.

IMHO, this flag approach only makes sense when the flag is cheap and 
initialized early. For example, in the corresponding `make_error_code` 
overload.

   inline error_code make_error_code(my_error err)
   {
     return error_code(err,
       err < min_success || err > max_success,
       my_category);
   }