On Fri, May 6, 2011 at 1:51 PM, Evan Driscoll <driscoll@cs.wisc.edu> 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