buffered input

Torarin torarind at gmail.com
Sun Feb 6 19:08:03 PST 2011


2011/2/7 Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org>:
> On 2/6/11 9:47 PM, Torarin 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? Maybe you could use appendToFront if you
>> knew that you needed to expand the stream's buffer, but that doesn't
>> sound like a common case.
>>
>> Torarin
>
> Exactly. Consider line continuations. Most of the time you read one line at
> a time and everything goes swell. On occasion you'll have a line
> continuation convention (line ends with a backslash, unmatched quote etc.)
> and you need to expand the current buffer to gobble the next line.
>
>
> Andrei
>

Yes, it's really convenient. You don't have to start messing with your
own buffer, and you avoid the temptation of doing one-element reads.
What seems more unlikely is using it on an empty front, though.

Torarin


More information about the Digitalmars-d mailing list