|
Boost : |
From: Peter Dimov (pdimov_at_[hidden])
Date: 2008-06-02 15:42:05
Frank Mori Hess:
> On Monday 02 June 2008 13:02 pm, Peter Dimov wrote:
>> That aside, I'm not sure why you need future_value semantics. Let's
>> assume
>> that one has a primitive
>>
>> future<R> async( F f, A1 a1, ..., An an );
>>
>> that schedules bind(f,a1,a2,...,an) for execution. It wouldn't be hard to
>> make it recognize when Ai is future<Bi>
>
> Oh, I came up with a reason that having future_value objects as inputs can
> be
> preferable to the solution you describe. Your solution forces the
> "lifted"
> functions to always take templates arguments. But template methods can't
> be
> made virtual. Also, you can't pass them to bind() without manually
> specifying all the template parameters.
Hm. I'm not sure I follow. Let's say that I have:
struct A
{
virtual int f( long x ) = 0;
};
int g();
future<int> h( A* pa )
{
return async( &A::f, pa, async( g ) );
}
What's the problem with the outer async recognizing that its third argument
is a future and treating it as a dependency?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk