Re: [boost] Re: A new boost::thread implementation?

From: David Abrahams (dave_at_[hidden])
Date: 2003-02-10 10:29:53

"Peter Dimov" <pdimov_at_[hidden]> writes:

> David Abrahams wrote:
>> "Peter Dimov" <pdimov_at_[hidden]> writes:
>>
>>> I am not saying that this is never useful, but syntax should target
>>> the typical scenario, not corner cases.
>>
>> Agreed.  I suppose that you'll say it doesn't target the typical
>> scenario because of its confusability.  I wouldn't argue.  Any other
>> reasons?
>>
>> What about:
>>
>>     result(f)
>
> Unqualified? ;-)

Good question ;-)

Maybe so, for the generic case.  If you know you're dealing with
Boost.Threads, then qualified should work.

>>> It makes a lot more sense (to me) to reserve operator() for the
>>> Runnable concept, since that's what Boost.Threads currently uses.
>>
>> And prevent any other concepts from using operator()?  Surely you
>> don't mean that.
>
> No, I meant in that particular case.

Okay.

> We have three concepts: Runnable, Executor (executes Runnables), and
> HasResult (for lack of a better name.) The AsyncCall concept I had in mind
> is both Runnable and HasResult, so it can't use operator() for both.
> x.result() or result(x) are both fine for HasResult.

I see that you separate the initiation of the call from its creation.
I was going under the assumption that a call IS a call, i.e. verb, and
it starts when you construct it.  An advantage of this arrangement is
that you get simple invariants: you don't need to handle the "tried to
get the result before initiating the call" case.  Are there
disadvantages?

I'll also observe that tying initiation to creation (RAII ;-)) also
frees up operator() for other uses.  It is of course arguable whether
those other uses are good ones ;-)

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com