From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-09-10 09:39:55
From: "Ed Brey" <edbrey_at_[hidden]>
> In this case, it is exactly the cleanliness of the OO design that I find
> the member functions break. The reason is that the wait functions are
> not primarily acting on the object, but rather on the current thread.
> The item being waited for is just a parameter, much as is auto_ptr x in
> the statement: y.reset(x). In this case, the object being acted upon
> doesn't have a variable name, since it is the current thread. We could
> make a global called this_thread, so one could have
> this_thread.wait_for(something). That reads very nicely, but so does
> wait_for(something), and it avoids the hassle of the global variable
> just for syntactic sugar. Still, the strongest argument seems to be how
> the interface becomes very consistent and easy to read, with code always
> looking like wait_for(something), where something is a magic overload of
> all things that could be waited for.
I mostly agree with your pro-free arguments mainly because I've already came
to the same conclusion (they are logically 'members' of the current thread.)
But your proposed uniform wait() syntax doesn't work AFAICS. wait() on a
condition variable needs additional argument(s).
-- Peter Dimov Multi Media Ltd.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk