buffered input

[Andrei Alexandrescu]

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