Le 24/08/15 00:17, Niall Douglas a écrit :
On 23 Aug 2015 at 23:57, Vicente J. Botet Escriba wrote:
I believe that I need something more about monad<T> than what I have found in the documentation. If there is anything missing, please do say in detail.
BTW, the link to Boost.Monad [1] is broken in https://boostgsoc13.github.io/boost.afio/doc/html/afio/overview.html. I profoundly apologise. In preparation for this review I relocated the Boost.Monad documentation onto GitHub's web service at https://ned14.github.io/boost.monad/ as it's more reliably there than ci.nedprod.com.
I obviously forgot to update the link in the AFIO docs, despite having specifically moved the docs for this purpose. It's fixed now on develop branch. Thanks for the spot. Is this link part of the review? I don't believe, so could you point me where the monad class is documented in AFIO? If it is not documented, why it is used so broadly.
Just a question, does the user need to use some APBind interfaces or is this just an internal implementation detail (Sorry, I don't know nothing about APBind)? If you want AFIO to use Boost.Thread, you define BOOST_AFIO_USE_BOOST_THREAD=1 before including. Else it uses the STL thread. The same goes for BOOST_AFIO_USE_BOOST_FILESYSTEM and ASIO_STANDALONE.
If you want to always use latest AFIO, you bind afio like this:
namespace afio = boost::afio;
If you want to pin a specific ABI which won't break in the future, you bind afio like this:
namespace afio = BOOST_AFIO_V2_NAMESPACE; Where can I find the description of this macro on the reference documentation?
That's probably all most people care about. More advanced stuff can be seen at https://boostgsoc13.github.io/boost.afio/doc/html/afio/FAQ/multi_abi.h tml.
It will be easier to know the scope of the review and what is left for the near future. Is the monad part of the review? I am happy to accept bug reports on monad<T>. But I don't think the AFIO review is reviewing monad<T>, nor do you need to. If class monad is not included in AFIO, the documentation shouldn't use it.
I mean, if you like the design of boost::shared_future<T>, then by definition you like the design of monad<T>. I would have said monad<T> is therefore uncontroversial, as it's already in Boost.Thread and is very well understood (especially by you Vicente!). I've already post in this ML some of my concerns respect to this class.
Just everywhere where you see monad<T>, replace it in your mind with boost::shared_future<T>. It has the same API and same behaviour.
I would prefer to don't need to do that. You say that monad is like a shared_future ready, so why don't you just replace the uses of monad by shared_future<T> in the documentation so we know of what we are talking of. Sorry but I can not review a document that makes reference to things that are not yet adopted by Boost. 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. Best, Vicente