$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] [Boost-users] [afio] Formal review of Boost.AFIO
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-08-23 18:17:58
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.
> 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;
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.
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!).
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.
Niall
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/