buffered input

[Torarin]

2011/2/7 Robert Jacques <sandford at jhu.edu>:
> On Sun, 06 Feb 2011 21:47:48 -0500, Torarin <torarind at gmail.com> wrote:
>
>> 2011/2/7 Robert Jacques <sandford at jhu.edu>:
>>>
>>> On Sun, 06 Feb 2011 10:43:47 -0500, Andrei Alexandrescu
>>> <SeeWebsiteForEmail at erdani.org> wrote:
>>>
>>>> On 2/6/11 6:01 EST, Tomek Sowiński wrote:
>>>>>
>>>>> Nick Sabalausky napisał:
>>>>>
>>>>>> discard and fetch?
>>>>>
>>>>> I like that.
>>>>
>>>> What's missing is the part that they refer to front. Maybe
>>>> discardFromFront() and fetchToFront()? But then I like
>>>> discardFromFront()
>>>> and appendToFront() better - the latter is about as long and more
>>>> informative.
>>>>
>>>> Don't forget that these are relatively rarely used.
>>>>
>>>>
>>>> Andrei
>>>>
>>>
>>> Actually, I don't think these functions would be relatively rarely used.
>>> I
>>> don't see that many people using a buffered input's popFront. Instead I
>>> see
>>> shiftFront in its place and an appendToFront call has to be made whenever
>>> buffer.front.empty.
>>>
>>
>> Why not popFront if empty?
>
> Because even reading UTF-8 requires more than 1-byte of information.
> Basically, any routine that processes a raw stream is going to have to
> handle the case where what they're processing straddles the buffer boundary.
> Now, if the routine wraps the raw stream in some higher-order range, such as
> byLine, which guarantees them that none of their inputs straddle, great. But
> it would be negligent to neglect those coders writing the higher-level
> ranges.
>

But popFront also reads more than 1 byte. Unless you call
appendToFront with a larger value than the current buffer size, unless
I have misunderstood, they should end up doing the same thing.

Torarin