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
>> What about:
> 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 www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk