"Andrei Alexandrescu" <seewebsiteforem...@erdani.org> wrote in message news:iil64l$1f6s$1...@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].