From: Boris (boris_at_[hidden])
Date: 2005-04-25 18:31:43
Rob Stewart wrote:
>> I was under the false assumption that "s << a" either completes
>> successfully or fails completely. But you are right: If a part of
>> object a is sent we don't know. Thanks for jumping in! I agree now
>> that socket streams can only support blocking I/O.
> It is possible to get the condition you describe, too, But my
> example was a typical insertion expression in which multiple
> insertions are done on one line and the result isn't checked
> until after:
> s << a << b << c << d;
> Ignoring the possibility that any of those insertions only
> partially completed because of UDT insertion operators, for
> example, you don't know which insertion (of a, b, c, or d)
> failed if the result of the expression is false (i.e., if
> s.good() is false).
I understand your point but still think this is true for any stream. There
might be other ways to find out where insertion breaks (like in your example
with a file) but then you leave of course the stream interface and don't use
However I withdraw the idea of non-blocking I/O support in socket streams
anyway as we can't know with the standard interface if "s << a" fails
> Note that you can use unformatted input/output functions on
> streams. Those could reasonably offer async I/O since they
> effectively just forward to the underlying streambuf for I/O.
> However, you still have to figure out how to report EWOULDBLOCK.
I don't know how many developers require non-blocking unformatted I/O
functions. I think most developers like streams because of code like "s << a
<< b << c << d". It's probably not worth the effort to support non-blocking
unformatted I/O functions. If anyone thinks differently he should tell us
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk