buffered input

[Jonathan M Davis]

On Saturday 05 February 2011 07:16:45 Andrei Alexandrescu wrote:
> On 2/5/11 5:09 AM, Jonathan M Davis wrote:
> > Hmm. I think that I'd have to have an actual implementation to mess
> > around with to say much. My general take on buffered input is that I
> > don't want to worry about it. I want it to be buffered so that it's more
> > efficient, but I don't want to have to care about it in how I use it. I
> > would have expected a buffered input range to be exactly the same as an
> > input range except that it doesn't really just pull in one character
> > behind the scenes. It pulls in 1024 or whatever when popFront() would
> > result in the end of the buffer being reached, and you just get the
> > first one with front. The API doesn't reflect the fact that it's
> > buffered at all except perhaps in how you initialize it (by telling how
> > big the buffer is, though generally I don't want to have to care about
> > that either).
> 
> Transparent buffering sounds sensible but in fact it robs you of
> important capabilities. It essentially forces you to use grammars with
> lookahead 1 for all input operations. Being able to peek forward into
> the stream without committing to read from it allows you to e.g. do
> operations like "does this stream start with a specific word" etc. As soon

The thing is though that if I want to be iterating over a string which is 
buffered (from a file or stream or whatever), I want front to be immutable(char) 
or char, not immutable(char)[] or char[]. I can see how having an interface 
which allows startsWith to efficiently check whether the buffered string starts 
with a particular string makes good sense, but generally, as far as I'm 
concerned, that's startsWith's problem. How would I even begin to use a buffered 
range of string[] as a string?

Normally, when I've used buffered anything, it's been purely for efficiency 
reasons. All I've cared about is having a stream or file or whatever. The fact 
that reading it from the file (or wherever it came from) in a buffered manner is 
more efficient means that I want it buffered, but that hasn't had any effect on how 
I've used it. If I want x characters from the file, I ask for x characters. It's 
the buffered object's problem how many reads that does or doesn't do.

You must be thinking of a use case which I don't normal think of or am not aware 
of. In my experience, buffering has always been an implementation detail that you 
use because it's more efficient, but you don't worry about it beyond creating a 
buffered stream rather than an unbuffered one.

- Jonathan M Davis