Boost logo

Boost :

Subject: Re: [boost] Monad (was: Re: [Boost-users] [afio] Formal review of Boost.AFIO)
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-08-27 22:38:42

On 27 Aug 2015 at 5:05, Glen Fernandes wrote:

> Niall Douglas wrote:
> > The idea is that no one ever need implement the Concurrency TS
> > themselves ever again. Just pick up a copy of Boost.Monad/Outcome.
> > Write your policy class for your custom variant. Profit.
> Is anyone besides Boost or standard library vendors actually interested in
> doing this? Standard library implementors are not going to take a dependency
> on a Boost library.
> For example: Are there many (or any) Filesystem TS implementations that
> people care about outside of standard library implementations and Boost?
> I just can't imagine someone, say, proposing Boost.Path that provides a
> boost::basic_path that can be used to implement
> std::experimental::filesystem::path and expecting anyone to care about it.
> Anyone implementing the TS will just implement
> std::experimental::filesystem::path themselves and not take a dependency on
> boost::basic_path to do it.
> What makes your basic_future so different to the hypothetical basic_path?

A basic_path is probably not going to attract much need for
customisation without losing interoperability with other basic_path

basic_future lets you implement any custom future type of your
heart's desire without losing wait composure with other custom

Also people do have a real need for custom futures. A big bone Chris
picks with the Concurrency model in the Concurrency TS is its
reliance on futures which he views (rightly) as being too chunky for
low latency socket i/o. My lightweight futures don't address all of
Chris' concerns, but they are a whole ton load better for low latency
work than standard futures.

If someone wanted even lower latency than my default implementation
and wanted to give up standards conformance, they certainly can do
that. My default implementation has to match the TS, and there is a
definite overhead to that.

I also suspect they'll be a real boon for C++ 1z coroutines given how
that is designed, but testing that is many months away yet. If they
are a real boon, I don't doubt Gor will be very interested.

Finally, you may not be aware that my lightweight futures are
dependent on a system future implementation. They do not replace
system nor Boost futures, they act as a layer implemented on top
dropping down onto the system futures when unavoidable.


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at