buffered input

[Nick Sabalausky]

"Andrei Alexandrescu" <SeeWebsiteForEmail at erdani.org> wrote in message 
news:iil64l$1f6s$1 at digitalmars.com...
> On 2/5/11 7:28 PM, Don wrote:
>>
>> Circular buffers don't seem like an 'optional' use case to me. Most real
>> I/O works that way.
>> I think if the abstraction can't handle it, the abstraction is a failure.
>
> The abstraction does handle it implicitly, except that it doesn't fix the 
> buffer size. If you ask for appendToFront() with large numbers without 
> calling shiftFront() too, the size of the buffer will ultimately increase 
> to accommodate the entire input. That's the infinite in infinite 
> lookahead.
>

But what about when the window straddles the border? Ex: The circular 
buffer's internal size is 1000, the current starting point is 900 and the 
window (ie, front()) is 200. I guess that could work fine if front() is a 
random-access range, but if it's an array (which I think is what you 
proposed unless I misunderstood), then front() would have to return a new 
allocation: buf[900..$]~buf[0..100].