On 2/5/11 6:57 AM, spir wrote:
On 02/05/2011 11:09 AM, Jonathan M Davis wrote:
Hmm. I think that I'd have to have an actual implementation to mess
around with
to say much. My general take on buffered input is that I don't want to
worry
about it. I want it to be buffered so that it's more efficient, but I
don't want to
have to care about it in how I use it. I would have expected a
buffered input
range to be exactly the same as an input range except that it doesn't
really
just pull in one character behind the scenes. It pulls in 1024 or
whatever when
popFront() would result in the end of the buffer being reached, and
you just get
the first one with front. The API doesn't reflect the fact that it's
buffered at
all except perhaps in how you initialize it (by telling how big the
buffer is,
though generally I don't want to have to care about that either).
[...]
Regardless, a more normal range could be built on top of what you're
suggesting,
and it could do essentially what I was thinking buffered ranges would
do. So,
perhaps doing what you're suggesting and building what I was thinking
of on top
of that would be the way to go. That way, if you actually care about
messing
with the buffer, you can, but if not, you just use it normally and the
buffering
is dealt with underneath.
Exactly. I would love something like:
auto bufInputRange (R) (R inputRange, size_t capacity=0) if (...)
Meaning one can specify (max) buffering capacity; else there is a
standard (re)sizing scheme. Just like dyn array (re)sizing.
Side-question to specialists: What should actual buf capacity depend on?
Denis
My design would allow you to build a buffered input range from an input
range, but only with infinite capacity.
Andrei
