On Sat, 05 Feb 2011 17:22:01 -0500, Nick Sabalausky <a@a.a> wrote:
"Heywood Floyd" <soul...@gmail.com> wrote in message
news:mailman.1318.1296941395.4748.digitalmar...@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.
See point of Andrei's post:
1. R is an input range of T[]
Which means that front returns an array, not a single element. So they
sound like they operate on the first element, because that's exactly what
they do. Conceptually, you need to think of buffered inputs as range of
ranges, not a range of elements.
