Subject: Re: [boost] Reforming Boost.System and <system_error> round 2
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2018-01-16 14:59:27
> The semantics of this `if(ec)` is "conditionally well-defined":
> provided that you make sure that in all error categories you use throughout
> your program zero indicates success and non-zero values indicate failure,
> then (and only then) does this construct test if `ec` represents a failure.
> Some programs can guarantee that, e.g. if they only use the default
> category on Unix.
However there are plenty of C error coding schemes with many values for
... and so on. C++ 11's error_code's `if(ec) ...` doesn't handle these,
and as Chris mentioned, it was never designed to do so. Though
error_code itself handles them perfectly fine.
Originally, `if(ec)` meant "if error code". Of course, recent C++ isn't
so sloppy anymore, we no longer should write `if(x)` when we mean `if(x
!= 0)`. And clang-tidy et al warns now appropriately.
That cultural shift in best practice is part of the cause of this debate
with `if(ec) ...`. The programmer is writing that, and usually expecting
it means something that it currently does not. After all, testing a
smart pointer by boolean check means "is the smart pointer pointing to
So are we reaching a consensus towards or away from the proposed change?
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk