From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-09-22 20:32:55
----- Original Message -----
From: "Peter Dimov" <pdimov_at_[hidden]>
> The point is that overloading a name to mean different things in different
> contexts is not necessarily a good thing. An overloaded name implies that
> don't care about the specifics of the call. I simply say x + y and expect
> to do the right thing. Obviously, when I say wait(x) I do care about which
> 'wait' variation is being performed.
Just as when you do std::cout << x you care about which streaming variation
is being performed... but there is a single way to stream that's appropriate
for each type you can use for x. Trying to remember a separate name for each
of the streaming operations just makes life harder.
> The 'join' variation invalidates x;
I think seeing it that way requires a kind of "manufactured ignorance" that
there is any threading. Join actually /waits/ for x to become invalid.
> 'sleep' variation doesn't modify x; the pthread_cond_wait variation has
> least) an additional mutex argument that it implicitly releases and
I don't know enough about what these mean to comment.
> In short, the semantics of wait(x, ...) are radically different. Given the
> template<class T> void f(T & t);
> I can't simply say wait(t) inside and trust it to perform the right kind
> operation. I have to know what t is, and if I do know that, why define the
> function as a template?
Precisely. And how would having different names help with this situation?
> (The Win32 API is a good example of why this kind of wait() overloading
> doesn't really work.)
> Now if you refine the wait() semantics a little, saying that wait(e)
> the current thread until the event e occurs, and then provide a way to
> specify a 'thread finished' event, a 'time reached' event, a 'predicate is
> true' event, I'll be inclined to agree with you.
How does the above differ substantially from what we'd get if we just gave
the current wait/sleep/join semantics the same name?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk