Re: [Boost-users] offlist - Re: [iterator] Problems with iterator_facade and const-qualification

Subject: Re: [Boost-users] offlist - Re: [iterator] Problems with iterator_facade and const-qualification
From: Dave Abrahams (dave_at_[hidden])
Date: 2011-05-08 13:54:12

On Sat, May 7, 2011 at 5:50 PM, Neil Groves <neil_at_[hidden]> wrote:
> On Sat, May 7, 2011 at 5:52 PM, Dave Abrahams <dave_at_[hidden]> wrote:
>>
>> On Fri, May 6, 2011 at 1:51 PM, Evan Driscoll <driscoll_at_[hidden]>
>> wrote:
>> > On 05/06/2011 11:59 AM, Jeff Flinn wrote:
>> >>
>> >> You might google any_iterator, and see how other authors have addressed
>> >> similar problems.
>> >
>> > Great! I tried to find someone who had done something similar, figuring
>> > I
>> > couldn't have been the first, but all the search terms I tried were too
>> > generic.
>> >
>> > Thanks,
>> > Evan
>>
>> You can find one in the ASL that's built on iterator_facade.
>> http://stlab.adobe.com/classadobe_1_1any__iterator.html
>>
>
> The underlying Boost.Range implementation implements an any_iterator that I
> believe to be similar to the one in ASL in terms of functionality. I believe
> that  the small-buffer optimization implementation

Oh, great idea!

>  is superior to forcing
> the definition of a closed-set of possible type as suggested in a TODO
> within the ASL documentation. During my performance testing I had
> considerably superior performance than the ASL implementation.
> I wondered if you disliked my implementation, or had any feedback.

No, I just didn't know about it!  I should have recommended that instead.

> Additionally I wondered what you thought about moving the Boost.Range
> internal any_iterator implementation into Boost.Iterator.

A capital idea!

> I can't honestly
> imagine a good use-case for using any_iterator in preference to any_range,
> hence I haven't suggested this previously.

Infinite ranges?  Output iterators?

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