Re: [boost] expected/result/etc

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 
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.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/