From: Boris (boris_at_[hidden])
Date: 2005-04-22 17:37:32
Rob Stewart wrote:
> From: "Boris" <boris_at_[hidden]>
>> 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
>>>> 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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk