Boost logo

Boost :

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

on Mon Jul 27 2009, Andrei Alexandrescu <> wrote:

> David Abrahams wrote:
>> on Fri Jul 24 2009, Andrei Alexandrescu <> 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 =
> Since there is reassignment, a possibility is to:
> (a) have 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at