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?
I'm just advocating that the lowest level API should provide this functionality. Streams operate at a higher level.
After following most of the discussions I think this is broad consensus. That's why http://www.highscore.de/boost/net/packages.png looks like it does. Boris