Re: [boost] expected/result/etc

Subject: Re: [boost] expected/result/etc
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2016-02-12 05:22:48

On 11 Feb 2016 at 18:00, Emil Dotchevski wrote:

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

As I said during the peer review, people who think they want async 
file i/o are generally disappointed. What people really want is 
*control* which normally means low worst case latencies, but in the 
filing system synchronous i/o is almost always lower worst case 
latency than async so firing 10,000 threads at a file i/o problem 
might actually be sensible. AFIO v1 delivered oodles of control, but 
packed very substantial work into file open and close (both of which 
are horribly slow anyway so it made sense) in order to keep 
everything else fixed overhead.

Now, I can totally see that if you want to open and close a lot of 
files, AFIO v1 is going to be not great for you, and v2 is going to 
be a lot better. People got upset with the find regex in files 
performance for example, and that was understandable: AFIO v1 is a 
poor choice for that use case.

In this sense the v2 design is much more flexible and reusable, but 
the end user programmer will have to work far harder than with v1 and 
have a far deeper understanding of filing systems to get reasonable 
results. The single biggest reason I won't be presenting v2 for peer 
review is the enormous documentation which would be required, it's at 
least six months of work and probably more, and I just can't afford 
such an enormous loss of income.

Still, what I learned from the Boost peer review is people here hate 
to be hand held, and I get that. And let me be very clear, the AFIO 
v2 design has a lot of merit, I don't disagree with any of it, I just 
think it excessive for its likely use cases - it is going to be 
several times lighter weight than ASIO which makes zero sense for 
file i/o vs socket i/o.

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

If the compiler can see all possible throw sites, and it is not 
called MSVC, then yes.

I don't think people's issue is about what happens in practice under 
optimisation. They want *guarantees*. They want to see noexcept on 
every function because it's a *guarantee* that no matter what the 
programmer does, no unbounded execution times will occur.

This is why games, audio and HFT shops ban the STL and disable RTTI 
and exceptions. It's about assurance, not reality in practice.

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

A lot of this debate isn't about empirical reality, if C++ 
programmers were managed by reality everyone would be using the STL 
with exceptions and RTTI turned on for years now.

As I mentioned, it's about *assurance*: given a pool of average 
programmers, how can you (technical leads and management) be assured 
they will write on average low worst case latency C++? This is why I 
expect exceptions disabled C++ to remain around for a long time to 
come, and why AFIO v2 and Outcome will eventually support exceptions 
disabled.

Niall

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