buffered input

[spir]

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