Boost logo

Boost :

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.


> 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

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at