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

16 Jan 2018

      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 
:
...
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);
   }