Boost logo

Boost :

Subject: Re: [boost] [afio][v1.30 "C++ Now edition" released]
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-03-19 21:05:39

On 19 Mar 2015 at 21:26, Mathias Gaunard wrote:

> So v1.4 will be the interface that will be submitted for inclusion into
> Boost?

v1.0 was the interface submitted for inclusion into Boost. It
reflected the state of C++ in 2013 where XP compatibility was still
very important, and therefore so was VS2010 compatibility. Every
version thence is also submitted for inclusion until a review
happens, which I assume will come back with a long list of changes
needed anyway.

If you're really asking when would I expect to finish the major
refactoring, currently I expect v1.4 to be the last. However, I
thought that about v1.3 during v1.2.

A lot of this is outside my control of course. Had WG21 gone for
Chris's concurrency proposal for example, I'd be refactoring in a
very different direction. This is a big consequence of being the
first C++ 11 only Boost library to enter the community review queue -
you build in not just your own technical debt, but also the technical
debt of the C++ language itself, *plus* that of the Microsoft
compiler team, the libstdc++ team, the mingw team and so on. In fact
the oldest compiler from v1.0 still supported identically is clang,
because they had the most complete C++ 11 support the earliest, so
clang 3.2 still works perfectly. As the ecosystem collectively
reaches closer to conformance to the standard and therefore to each
other, I can keep ripping out workaround patterns which used to make
sense before but don't anymore.

I'll put this another way. Back in v1.0 future-promise looked fast
and buggy, but then the engine could only push 150k ops/sec. By v1.2
future-promise looked slow because it could now push 1.5m ops/sec. So
by me ripping out the shared_ptr workarounds, I made the performance
spotlight fall on other code. As I fix that, spotlights shine
elsewhere and more fixes are needed.

At some point both the C++ language ecosystem changes will settle
down, and nails will stop sticking up to be hammered down. I'd expect
API maturity to start then, same as any other Boost library. At that
point I'll start building the embedded graph database AFIO is
intended for.

> > AFIO uses ASIO's event loop. It doesn't use the async_result idiom of
> > ASIO because for file i/o you want strong graph ordering, and that's
> > a pain to do with async_result. A more functional idiom, for which I
> > chose future-promise, makes strong ordering much easier to program.
> > Once I get Fibers/resumable function support in there next release,
> > writing strongly graph ordered filing system algorithms ought to
> > become optimally easy, and then I can get down to writing race free
> > tree visitors etc which right now are very messy to write and debug.
> I think it would be useful to be able to make use of the future-promise
> idiom for other ASIO code as well.

ASIO already provides future-promise support via asio::use_future.

> Is it possible to use your futures for any ASIO async_result?

Absolutely. Mine has just standard shared_futures, same as the ones
ASIO uses.

The custom afio::future in v1.4 will also work perfectly in ASIO,
indeed I'll be providing the async_result specialisations so it's
just as seamless to use. ASIO has Fiber support too, so Fiber should
seamlessly multiplex ASIO and AFIO i/o for you. You just glue
together the logic with resumable functions, and let the runtime
figure it out for you. Which will be neat.


ned Productions Limited Consulting

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