buffered input

[Nick Sabalausky]

"Ellery Newcomer" <ellery-newcomer at utulsa.edu> wrote in message 
news:iiiu0g$2kmp$1 at digitalmars.com...
>
> Does shiftFront literally move element n to index 0 and so on? It seems to 
> me that if you do, its going to have horrid performance, and if you don't, 
> then you will eventually run into situations where appendToFront will 
> require a wrap around, which loses you your contiguity, or a reallocation 
> of the buffer.

That's what I was wondering too. Would it be forced to internally do a bunch 
of "buf[x..$]~newStuff" and march itself through memory? Would it be 
sensible to use that interface for a circular buffer? If so, how would you 
even do it?

On a separate note, I think a good way of testing the design (and end up 
getting something useful anyway) would be to try to use it to create a range 
that's automatically-buffered in a more traditional way. Ie, Given any input 
range 'myRange', "buffered(myRange, 2048)" (or something like that) would 
wrap it in a new input range that automatically buffers the next 2048 
elements (asynchronously?) whenever its internal buffer is exhausted. Or 
something like that. It's late and I'm tired and I can't think anymore ;)