Re: [boost] Re: (Another) socket streams library

From: Aaron W. LaFramboise (aaronrabiddog51_at_[hidden])
Date: 2005-05-04 00:11:41

Nathan Myers wrote:

> After there's text in the 
> buffer, you can decide if it's enough to merit calling whatever is 
> supposed to extract and operate on it.

It seems that if you already have code that does this by directly
examining the buffer, there may be little point in dropping back a level
of abstraction and then using operator>>.  In particular, in a common
case, verifying whether input is complete does most of the work of
actually extracting it.

But still I think something special is needed here, because in the case
of integers, for example, theres no particular way to tell whether an
integer is complete or not without having some metadata.

One thing I've never understood is how extractors are supposed to be
written when they require reading two or more sub-objects from the input
stream.  If reading the first part suceeds, but the second part fails,
what happens to the chunk of data that was read?  And how do we prevent
the stream from being in an indeterminant state due to not knowing how
much was read?  Perhaps the solution to this problem might present new
ideas for solutions to the nonblocking extractor problem.

Aaron W. LaFramboise