buffered input

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Sun Feb 6 20:01:12 PST 2011


On 2/6/11 10:59 PM, Robert Jacques wrote:
> 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.

They aren't being neglected. If you need to get more stuff in the 
current unit of work, use appendToFront().

Let's restart this. What do you want to do that you can't do with the 
proposed API?

Andrei


More information about the Digitalmars-d mailing list