Boost logo

Boost :

Subject: Re: [boost] This AFIO review - a modest proposal
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-08-24 17:24:59

On 24 Aug 2015 at 11:52, Glen Fernandes wrote:

> Niall Douglas wrote:
> > And I have no problem if AFIO never enters Boost. I would think it a
> > shame and a wasted opportunity as it solves a ton of pain points for
> > those with such needs
> Whatever happened to...
> > Niall Douglas wrote:
> > > Firstly, you don't invest the multi-year effort to get a library
> into
> > > Boost because it's superior, as it probably isn't. You do it
> because
> > > of what you will become after you succeed: a Boost library author
> > > who has passed the judgement of his or her peers.

Remember I have more than one Boost library coming :)

AFIO will be the hardest to get in because it's so niche, and I've
known that since the beginning. Monad will be hard to get in because
it's too fundamental and everyone will have their own opinion and
think they know better despite not having written one themselves, so
we won't reach consensus. It'll just descend into argument.

My final planned Boost library before I move on from Boost to warmer
climes is a reliable (a)synchronous transactional key-value store
implemented using AFIO and Monad. That will get into Boost without
issue because *everybody* needs to persist state especially on
unreliable hardware. That will be the only unequivocably useful
library I propose for Boost which very little argument can be made
against, and I expect it will be unconditionally accepted. Once it's
in, it also becomes much harder to reject AFIO and Monad.

> On a more serious note:
> > Totally separate to the async file i/o is the race free filesystem
> > stuff. I would like to believe that people understand why a race free
> > filesystem API is important.
> Your documentation would be the best vehicle to convey (and prove) this. It
> doesn't do it for me right now. I may be the 0.0001% who doesn't need AFIO
> as you've currently designed it but ideally the documentation should help me
> understand why.

Ideally yes. But it's like writing long essays on why choose future
over async_result.

About 20% find it very useful and approve.

About 20% think it clutter, confusing and annoying because it's just
noise to them. You've seen people already say the AFIO documentation
goes into too much detail about things you don't need to know.

The remaining 60% don't care, and that suggests it has a poor cost
benefit when I could do other much more valuable things with the same
time than write essays on stuff more than half of people are
indifferent about.

In the end you're trapped. I take the view you don't ask uBLAS to
explain from first principles matrix mathematics in its
documentation. Why therefore ask the same of AFIO regarding file
system theory?


ned Productions Limited Consulting

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