buffered input

[Tomek Sowiński]

Andrei Alexandrescu napisał:

> > I don't see a clear need for the two to be separate. Could they fold
> > into popFront(n, m) meaning shiftFront(n); appendToFront(m) ? Nullary
> > popFront() discards all and loads any number it pleases.  
> 
> I think combining the two into one hurts usability as often you want to 
> do one without the other.

OK, but if you go this way, what would popFront() do?

> > Some users would benefit if they could just pass in a buffer and say
> > "fill'er up".  
> 
> Correct. That observation applies to unbuffered input as well.

Right.

> > Contiguous, yes. But I'd rather see front() exposing, say, a circular
> > buffer so that appendToFront(n) reallocates only when n>
> > buf.length.
> >  
> 
> I think circularity is an implementation detail that is poor as a 
> client-side abstraction.

I fear efficiency will get abstracted out. Say this is my internal buffer (pipes indicate front() slice):

[ooo|oooooo|oo]

Now I do appendToFront(3) -- how do you expose the expected front() without moving data?

-- 
Tomek