On 02/05/2011 11:22 PM, Nick Sabalausky 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.
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