Re: [boost] AlRangeExandrescu?

Subject: Re: [boost] AlRangeExandrescu?
From: Rogier van Dalen (rogiervd_at_[hidden])
Date: 2009-07-27 18:13:06

On Mon, Jul 27, 2009 at 18:42, Andrei
Alexandrescu<andrei_at_[hidden]> wrote:
> 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.

I just tried iteration with a (begin, end) range and immutable bump
without the proxy trick. I see no performance difference with using
raw pointers. This is gcc 4.3 and -O3.

> 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.

I started writing a prototype implementation of something like this
over the weekend. It currently uses a free function to bump a range.
"r = bump_front(r)" may be less confusing than a method. (My
motivation for using free functions was independent of this: the
interface of range adaptors seems to become cleaner.)

I would be very interested in unifying interfaces of homogeneous and
heterogeneous containers, and I'm now starting to believe that that is
actually possible. My interest is not entirely frivolous, because I've
started to need this recently.

Cheers,
Rogier