Boost logo

Boost :

Subject: Re: [boost] Futures vs async_result (was: Re: [afio] AFIO review postponed till Monday)
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2015-07-25 13:03:51


> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Niall Douglas
> Sent: 24 July 2015 18:48
> To: boost_at_[hidden]
> Subject: [boost] Futures vs async_result (was: Re: [afio] AFIO review postponed till Monday)
>
> On 22 Jul 2015 at 22:13, Michael Caisse wrote:
>
> > > I don't mind restoring such a section now that I have lightweight
> > > futures which do I think address most of the problems that the
> > > async_result camp have with futures. Do you think I should
> > > incorporate this rationale into the design rationale, the tutorial,
> > > or the FAQ?
> > >
> >
> > I personally do not think you need to restore the section. Some people
> > find the async_result clumsy. Some people think it is elegant. I
> > personally like the async_result interface and find it far more
> > flexible; however, I can work with a future interface just fine.
> >
> > You have mentioned a couple times that futures is the right choice for
> > file I/O and async_result is the right choice for network I/O. I
> > haven't really thought too much about it but I have some ideas on why
> > you might state that. I know you have thought about this problem
> > domain a lot and was interested in how/why you came to that conclusion.
>
> Oh okay. I can try my best to explain so.
>
> I assume everyone reading understands futures.

Assumption is the mother of all foul-ups!

I found this a useful summary - perhaps it should be in your documentation? Space is cheap.

(Especially as I suspect that lots of people who will use network I/O will not understand what they
are doing as much as perhaps they should - they want it to 'just work' - so they can concentrate on
their real task?).

<snip of your nice explanation>

Paul

---
Paul A. Bristow
Prizet Farmhouse
Kendal UK LA8 8AB
+44 (0) 1539 561830

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk