Re: [boost] [Boost-users] [afio] Formal review of Boost.AFIO

Subject: Re: [boost] [Boost-users] [afio] Formal review of Boost.AFIO
From: Darren Cook (darren_at_[hidden])
Date: 2015-08-24 03:42:57

>> We have two options:
>> * we wait to review AFIO once Monad is reviewed in Boost
>> * You include in AFIO, whatever you consider is need from Monad and only 
>> then we review AFIO.
> 
> I can remove monad<T> from all the tutorial code. Or I can include 
> documentation of monad<T> in AFIO. Which would you prefer?

You've mentioned monad<T> is just like std::shared_future<T>, and have
said the tutorial could be changed to use the latter. Could the whole
library be changed to use std::shared_future<T>. I think the answer is
no, so could you expand on why?

E.g. does it save typing because otherwise your code is littered with
p.get_future().wait() calls? Or does it save having to do tight polling
loops, and therefore improves latency? Or some other reason?

BTW, does Monad extend proposal N4399? (
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4399.html )
Would you recommend I be familiar with that, before reading the
Boost.Monad docs (https://ned14.github.io/boost.monad/index.html)?

I also have a similar implementation question, regarding asio: in one of
your emails (sorry, couldn't find it just now - it might have been
something I skimmed in the docs, yesterday), on performance, you said
that some of the overhead was adapting to something in asio. I wondered
in what way your library is tied to asio, and for what functionality in
your library it is an essential part. (Are any parts of the ASIO
interface exposed in the AFIO public API, or is it purely an
implementation detail?)

Thanks,
Darren