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

Subject: Re: [boost] [afio] Formal review of Boost.AFIO
From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2015-08-28 02:30:53

On 28 Aug 2015 6:34 am, "Thomas Heller" <thom.heller_at_[hidden]> wrote:
>
> On 08/27/2015 04:04 AM, Niall Douglas wrote:
> <snip>
> A lot of things about future vs. shared_future...
> </snip>
>>
>>
>> Thoughts?
>
>
> Ok, after reading all the other messages in this and other threads I am
starting to understand what the real problem is (all this is IMHO, of
course):
>
> The biggest mistake in your design is that of the functions taking
"preconditions". This brought you all this mess. The problem is, those are
actually not preconditions but actually arguments to the function, more
specifically, your "precondition" is always (?) the handle (or a future to
the handle so to speak) to the actual operation that is being performend
for which you need to get the value. That all is a result of the
non-existing single responsibility pattern in your code. After getting rid
of that, you will see that most of the points you brought up against using
std::future (or boost::future) will actually go away.
> Here is my concrete suggestion:
>  - Let your async functions return a future to their result! (Not a tuple
to the handle and the result...)
>  - Don't use futures as arguments to your async functions. Say what you
want as input!
>
> Let's take on your read example... and suppose we have the following two
function signatures:
>
> future<handle> open(std::string name);
> future<std::vector<char>> read(handle const & h, std::size_t bytes,
std::size_t offset);
>
> See how easy, clear and succinct those functions are? Almost self
explaining without any further documentation.
>

Couldn't possibly agree more. I was going to focus on this issue on my
review. Thanks for explaining it so well.

-- gpd