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

Subject: Re: [boost] Reforming Boost.System and <system_error> round 2
From: Richard Hodges (hodges.r_at_[hidden])
Date: 2018-01-16 13:55:42

Rather than change the meaning of the (ambiguous but no doubt ubiquitous)
bool conversion, might it not be better to offer a new method?

if (ec.is_error())
{
  // ...
}

is_error() could consult the error_category.

or better, ADL:

if (is_error(ec))
{
  // ...
}

re performance arguments:
The only time the performance cost a virtual call is relevant is when the
function is called in a tight loop. error_code is the result of a system or
system-like call. In a reasonable program, it's never called in a tight
loop.

On 16 January 2018 at 14:30, Andrey Semashev via Boost <
boost_at_[hidden]> wrote:

> On 01/16/18 02:37, Robert Ramey via Boost wrote:
>
>> On 1/15/18 1:18 PM, Niall Douglas via Boost wrote:
>>
>> That leaves the request to fix "if(ec) ..." which right now returns true
>>> if the value is 0, despite that much code writes "if(ec) ..." to mean
>>> "if error then ...". There is also the issue of error coding schemes not
>>> being able to have more than one success value, which usually must be 0.
>>> That's the remaining discussion point.
>>>
>>
>> I apologize for parachuting into the discussion ...  But ...
>>
>> Can't one just have "if(ec) ..." invoke a syntax error?
>>
>
> Obviously, this will break lots of code for no good reason. I think, the
> understanding of the meaning of such tests is more or less established. The
> problem is to make it support additional use cases without penalizing the
> existing code too much.
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman
> /listinfo.cgi/boost
>