David Abrahams wrote:
on Mon Jul 27 2009, Andrei Alexandrescu <andrei-AT-metalanguage.com> wrote:
David Abrahams wrote:
on Fri Jul 24 2009, Andrei Alexandrescu <andrei-AT-metalanguage.com> wrote:
Is popFront() mutable just for efficiency? Or is there something else I'm missing? It's only efficiency. I was very attracted to popFront returning the new range (100% functional interface!) but I gave up for efficiency reasons. I didn't want iteration with ranges to be cool and iteration with other means to be efficient. Could you describe the efficiency problem in more detail? I think it might be solvable. Well a simple example is that a range in a contiguous array is a fat pointer, e.g. (begin,end). To bump a range in-place you need to change one pointer; returning a new range would have you copy two pointers. It turns out that the difference is sensible for some loops.
If compilers can't optimize that overhead away, I'm disappointed in them ;-(
Did you check?
I did, but not the trick with the proxy. One other source of concern was that people would write r.next() instead of r = r.next() (expecting that r.next modifies r in place) and then get confused that they got an infinite loop. In contrast, writing r = r.popBack() is a compile-time error because popBack returns void, so there's no doubt that r.popBack() is the expected way to bump a range. Andrei