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