Boost logo

Boost :

From: Boris (boris_at_[hidden])
Date: 2005-04-22 13:54:23

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 looks like it


Boost list run by bdawes at, gregod at, cpdaniel at, john at