Boost logo

Boost :

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


ned Productions Limited Consulting

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