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
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk