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

Subject: [Boost-users] offlist - Re: [iterator] Problems with iterator_facade and const-qualification
From: Neil Groves (neil_at_[hidden])
Date: 2011-05-07 17:50:17

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 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.
Additionally I wondered what you thought about moving the Boost.Range
internal any_iterator implementation into Boost.Iterator. 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. This could easily be due to my
lack of imagination! Can you think of a time when using an any_iterator on
any interface would be superior to using an any_range?

Your opinions and guidance would be much appreciated.

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

Regards,
Neil Groves