buffered input

[Andrei Alexandrescu]

On 2/5/11 1:18 PM, Tomek Sowiński wrote:
> 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?

Discard everything in the current buffer and fill a new buffer. The new 
size depends on the stream; for byLine a new line would be read, for 
byChunk(4096) 4096 more bytes would be read.

>>> 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?

You do end up moving data, but proportionally little if the buffer is 
large enough.


Andrei