buffered input

Nick Sabalausky a at a.a
Sat Feb 5 19:37:47 PST 2011


"Andrei Alexandrescu" <SeeWebsiteForEmail at erdani.org> wrote in message 
news:iil3lv$1bb1$1 at digitalmars.com...
> On 2/5/11 5:22 PM, Nick Sabalausky wrote:
>> "Heywood Floyd"<soul8o8 at gmail.com>  wrote in message
>> news:mailman.1318.1296941395.4748.digitalmars-d at puremagic.com...
>>>
>>> As in, you've built some library that passes around ranges, but then 
>>> some
>>> part of it is slow and needs buffered ones. Isn't the point that you can
>>> then swap out your ranges for buffered ones here and there, but continue 
>>> to
>>> have a functioning library?
>>
>> The problem with that is that in many many cases it forces unnessisary
>> copying. We can get much better performance with this slightly more
>> "hands-on" version. But that said, if the traditional "hands-free 
>> automatic
>> buffering" really is all you need, then such a thing [should] be easily 
>> to
>> construct out of the Andrei's style of buffered range.
>>
>>
>>> Then follows that popFront() means "discard the first _element_, so that
>>> the element that was second now becomes first." And if we can agree to
>>> that, then shiftFront() is possibly very confusing, and so is
>>> appendToFront(). They sound like they operate on the first element!
>>
>> I completely agree. The names of those functions confused the hell out of 
>> me
>> until I read Andrei's descriptions of them. Now I understand what they
>> do...but I still don't understand their names at all.
>
> Better names are always welcome!
>

Borrowing slightly from Adam:

discard and fetch?




More information about the Digitalmars-d mailing list