Boost logo

Boost :

Subject: Re: [boost] expected/result/etc
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2016-02-11 19:30:19

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

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.


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at