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

Subject: Re: [boost] [afio] Formal review of Boost.AFIO
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2015-08-28 00:50:26

On 28/08/2015 15:08, Hartmut Kaiser wrote:
>
>> On 28/08/2015 00:58, Hartmut Kaiser wrote:
>>> Third, the terminology 'consuming' and 'non-consuming' future does not
>> make
>>> any sense (to me). More importantly it is by no means Standard-
>> terminology -
>>> thus reasoning in terms of those makes it much more difficult for us to
>> talk
>>> about the same thing.
>>
>> future.get() moves the result of the promise from the internal state,
>> thereby consuming it.  Further calls to get() or then() fail.
>>
>> shared_future.get() copies the result of the promise from the internal
>> state, thereby not consuming it.  Further calls to get() or then()
>> succeed.
>
> All of this is an irrelevant implementation detail. Nobody forces the future
> to share its state with a promise. It could very well be a packaged_task,
> for instance, or any other asynchronous provider.

You're sidestepping.

Some mechanism results in the value given to the promise arriving at the 
future, and thereby allowing it to return the value from get() or invoke 
then() continuations.  For the purposes of this discussion I frankly 
don't care how that implementation is done, or whether it arrives via 
some other source such as a packaged_task.

However, the consequence of the front-end interface (future and 
shared_future) is as I described above.  One of them is one-use-only and 
the other allows multiple uses.  This is a visible and important 
characteristic -- in fact it is probably the *most* visible and 
important characteristic from a usage perspective.  And that is the 
perspective that Niall appears to be using as well.

Whether the future internally uses shared state or not is actually the 
inconsequential part from the perspective of users of the classes. 
(Except where it affects performance -- and even that is inconsequential 
to some users.  Perhaps even most users, given the prevalence of people 
saying "just use shared_ptr everywhere" not that long ago.)

> If somebody forgets, then an exception is the correct thing to do.
> Alternatively an assertion could be used in this case as well.
> BTW, an exception is not difficult to find, even gdb can break on a specific
> exception being thrown.

But only if the code path actually executes.  While in an ideal world 
the unit tests will have 100% coverage, we don't live in that ideal world.