Re: [boost] AlRangeExandrescu?

Subject: Re: [boost] AlRangeExandrescu?
From: David Abrahams (dave_at_[hidden])
Date: 2009-07-27 12:58:21

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?

> In the general case, an unbounded amount of state would have to be returned from
> r.next.
>
> Now, here's what I think you might be thinking. The idiomatic use is r =
> r.next(). Since there is reassignment, a possibility is to:
>
> (a) have r.next() return a small proxy type Proxy that saves a reference to the range
>
> (b) have Range::operator=(Proxy) detect reassignment from itself and only operate the
> minimum update.
>
> (c) also define Range::Range(Proxy) for completeness.
>
> After all has been said and done, the overhead is one word copied and
> one more test. I hadn't thought of that.

Yep, those are the lines along which I was thinking.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com