"Ellery Newcomer" <ellery-newco...@utulsa.edu> wrote in message news:iiiu0g$2kmp$1...@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 ;)