On Thu, Feb 11, 2016 at 4:30 PM, Niall Douglas
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