appendToFront semantics

Torarin torarind at gmail.com
Tue Feb 15 09:52:19 PST 2011


I've been experimenting with Andrei's buffered input range and noticed
that appendToFront(size_t n) may benefit from a slightly different
definition.

Andrei describes it as appending at most n elements to the front. But
if you change that to "at least", the range can ask the underlying
stream to also fill any unused space in the buffer.

If unused space is available before doing the append, this can also be
achieved by doing appendToFront(0) until you reach the desired
front.length. But if that leads to a move of buffered data, it becomes
less efficient than it could be.

The change means you would lose the ability to limit the amount read
from the underlying stream, which could be useful for a e.g. a
protocol switch, but I'm inclined to think that's less important than
the efficiency of the common case.

Did I miss the reason why this doesn't work well?

Torarin


More information about the Digitalmars-d mailing list