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
--
_________________
vita es estrany
spir.wikidot.com
