On 19/03/2015 20:37, Niall Douglas wrote:
So basically AFIO currently looks the way it does mostly due to legacy baggage and problems with C++ 11 back in 2013. Each release I refactor some of the baggage out. v1.3 was the first to drop < VS2013 support for example, it was a ton of work purging the VS2010 custom code paths. v1.4 will purge async_io_op + when_any/all and replace those with a proper C++ 17 compliant custom continuable future type which understands resumable functions. A big part of why that didn't enter v1.3 is because VS2015 and its resumable functions support I can test against isn't released yet, plus I was waiting for the Concurrency TS to firm up, it's only really stabilised these past six months.
Thanks for the clarification. So v1.4 will be the interface that will be submitted for inclusion into Boost?
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. Is it possible to use your futures for any ASIO async_result?