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 standard methods. 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 partially.
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 now! :) Boris