On 2010-01-29 12:21:18 -0500, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> said:
Michel Fortin wrote:
Yeah, it's less likely to be a problem. But "less likely to be a
problem" does still does not make things reliable. Something reliable
works all the time, or it just doesn't work and tells you.
stream.front after stream.popFront works all the time and fetches a new
line off the stream. Like Steve said, you can't at the same time fetch
a line and leave it back in the stream.
The problem is that algorithms that depends on this will work with
other ranges, but will fail silently when given a stream.
In all seriousness, even Java streams are better modeled than this
(although more limited by not having templates). The basic Java input
stream doesn't have a 'front' byte, you can only read the next byte (or
the few next bytes). If you need to rewind, there is a standard way,
but most streams need to be wrapped in a buffered stream first to
provide this capability.
So in our case, if you need to add a one-byte or a one-line buffer for
a filtering stream I think it should be done explicitly as it has side
effects on the underlying stream. In Java you do this by composition,
creating a buffered stream from another input stream when you need one.
Doing this implicitly, and especially creating a separate buffer each
time you create a new filtering range, is what makes the problem hard
to follow. Making 'front' lazy fetching will help in many cases, but
it'll never remove the problem entirely.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
