|
Boost : |
From: Dave Gomboc (dave_at_[hidden])
Date: 2005-08-20 11:26:56
> Sorry, I wasn't really clear before. The presence or not of the handler
> parameter is the difference in the function *signatures*. How the
> function actually behaves is quite different (a synchronous call blocks
> the calling thread, an asynchronous call never blocks). It is not the
> handler parameter that determines whether the operation is synchronous
> or asynchronous; the handler is just the function that is called when
> the asynchronous operation completes.
Actually, I understood how you intended it to work, but I had been trying
to convince myself that it's truly better for the asynchronous calls to
have a different signature than the synchronous call, and I wasn't able to
convince myself. So I was hoping that you'd do it. ;-)
The devil's advocate position remains: synchronous operation is merely the
particular case where the handling policy prevents the function from
returning control to the caller until the operation has completed; no
unique function signature is warranted.
> What do you think of my proposal in my email earlier today where
> basically I use "read" and "write" for the operations that are in the
> *Stream concepts (and so could equally apply to pipes, files and so
> on), but retain "send" and "receive" (and "send_to" and "receive_from")
> for operations that are specific to sockets?
It would be better if use of "read" and "write" were ubiquitious, but if
there's an overloading clash, I guess you have to do what you have to do.
Dave
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk