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. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/