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
