Re: [boost] expected/result/etc

Subject: Re: [boost] expected/result/etc
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2016-02-11 21:00:16

On Thu, Feb 11, 2016 at 4:30 PM, Niall Douglas <s_sourceforge_at_[hidden]>
wrote:

> On 11 Feb 2016 at 15:20, Emil Dotchevski wrote:
>
> > Niall's motivation is to make code like this safer without resorting to
> > exceptions. But the best way such code is made safe is by using
> exceptions.
>
> Sorry, I have to correct you here as this is an incorrect statement,
> and it's my own fault for me not correcting an earlier reply to a
> post of mine where you got a false understanding of my position.
>
> Fixed: I *like* exceptions, a lot. Indeed I default to them, as I did
> in AFIO v1 for handling all unexpected outcomes. In any new general
> purpose C++ I write either now or in the future will exclusively use
> exceptions.
>
> However, some of the AFIO v1 peer reviewers wanted a hard semantic
> distinction between catastrophic errors and benign failures (I can
> see a point here). Other peer reviewers wanted no more than a few
> hundred cycles overhead around the raw syscall (I think this daft
> personally). Quite a few took issue with the use of shared_ptr to
> manage lifetimes (also a daft criticism), and the more insightful
> reviewers took particular issue with the high number of allocations
> and free per operation performed due to the many stages of type
> erasure (I very much agree).
>
> Even though AFIO v2 probably won't go in for peer review on it own, I
> have implemented almost all of the peer review feedback. v2 throws no
> exceptions, allocates and frees exactly one malloc per operation,
> uses no threads and therefore doesn't need shared_ptr, and yes there
> are even less than a few hundred cycles overhead around the syscalls
> on Windows (not so on POSIX, AIO is shockingly awful and you need to
> spend a ton of cycles to make it sane). All possible outcomes from
> any AFIO v2 function are as tightly specified as POSIX itself right
> down to every potential error emitted.
>
> Outcome is a very large part of achieving this very lightweight AFIO
> v2 whilst leveraging as much of the power of C++ as possible in doing
> so. I personally speaking think such lightweightness is overkill for
> the use cases as file i/o is enormously heavy, but I defer to Boost
> peer review judgement. You'll get what you collectively asked for. I
> don't personally agree with it, but if one *has* to write this sort
> of lightweight C++, then I think Outcome a great help in doing so.
>

I'm not qualified to judge these design decisions, but I'm very skeptical.
You as the author of AFIO are an expert in this domain, or else you
wouldn't be writing this library. It's okay to defer to peer review
judgement as long as it is substantiated.

That said, whether or not a function throws exceptions is a design
decision, nothing to do with run-time overhead. The reason, again, is that
any exception handling overhead of calling a function can be easily
eliminated, by inlining. It is true that this will not make the function
work faster in the case when it does throw, but at that time we're usually
dealing with aborting an operation, it's an exceptional condition. I
understand that this may be a problem in some weird cases but that's when
I'd demand strong evidence rather than conspiracy theories and toy
benchmark programs.

Emil