Rob Stewart wrote:
From: "Boris" <boris@gtemail.net>
Caleb Epstein wrote:
[...]
Also, how should the stream object behave in case of EWOULDBLOCK? Set failbit? Even if we use a wouldblockbit, we still need to set failbit, as the only thing clear is that the operation was *not* successful.
I would not recommend combining non-blocking I/O with streams, at least not in any way that becomes visible to the user of the stream.
As far as I can see EWOULDBLOCK is just another reason for a stream to fail. If you use << or >> with streams you must be prepared for failure any way. The only difference with EWOULDBLOCK is that you have to call << or >> again. However if I think about it I wonder how reasonable non-blocking I/O streams are at all as they don't support multiplexing - the application would need to call << or >> again and again?
How would the user level code know which insertion or extraction to repeat in an expression like this:
s << a << b << c << d;
Socket streams supporting non-blocking I/O would require the user to check the result of I/O operations. However this should already be done with today's std::iostreams. If s is eg. of type std::ofstream and a call to << fails you have the same problem, don't you? Boris