buffered input

[spir]

On 02/05/2011 11: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.

Same here; thought: "maybe he meant shiftBuf() & appendToBuf(), or such?". 
(Then, as nobody reacted about that point, thought: "You're the stupid one; 
shut your mouth!")

I also agree with Heywood about first() / popFirst(). Then, shiftFront() / 
appendToFront() would be less confusing --but still hard to guess (for me).
I wonder if his "view window" is the whole or part of the buffer. Well...
(Else, I actually share most of Heywood's views, I guess, at least at first read.)

Denis
-- 
_________________
vita es estrany
spir.wikidot.com