offlist - Re: [iterator] Problems with iterator_facade and const-qualification
On Sat, May 7, 2011 at 5:52 PM, Dave Abrahams <dave@boostpro.com> wrote:
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
On Sat, May 7, 2011 at 5:50 PM, Neil Groves <neil@grovescomputing.com> wrote:
On Sat, May 7, 2011 at 5:52 PM, Dave Abrahams <dave@boostpro.com> wrote:
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
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
On May 8, 2011, at 1:54 PM, Dave Abrahams wrote:
On Sat, May 7, 2011 at 5:50 PM, Neil Groves <neil@grovescomputing.com> wrote:
Additionally I wondered what you thought about moving the Boost.Range internal any_iterator implementation into Boost.Iterator.
A capital idea!
+1 I've my own simplistic any_iterator, with a pending todo of adding SBO. I recently ran across Neil's any_iterator in a detail namespace of a boost version I'm not yet using, and was hoping it might become a public interface.
Kim Barrett wrote:
On May 8, 2011, at 1:54 PM, Dave Abrahams wrote:
On Sat, May 7, 2011 at 5:50 PM, Neil Groves <neil@grovescomputing.com> wrote:
Additionally I wondered what you thought about moving the Boost.Range internal any_iterator implementation into Boost.Iterator. A capital idea!
+1
I've my own simplistic any_iterator, with a pending todo of adding SBO. I recently ran across Neil's any_iterator in a detail namespace of a boost version I'm not yet using, and was hoping it might become a public interface.
+1 I didn't know about it either. Jeff
On Mon, May 9, 2011 at 1:24 PM, Jeff Flinn <TriumphSprint2000@hotmail.com>wrote:
Kim Barrett wrote:
On May 8, 2011, at 1:54 PM, Dave Abrahams wrote:
On Sat, May 7, 2011 at 5:50 PM, Neil Groves <neil@grovescomputing.com> wrote:
Additionally I wondered what you thought about moving the Boost.Range internal any_iterator implementation into Boost.Iterator.
A capital idea!
+1
I've my own simplistic any_iterator, with a pending todo of adding SBO. I recently ran across Neil's any_iterator in a detail namespace of a boost version I'm not yet using, and was hoping it might become a public interface.
+1
I didn't know about it either.
I have discussed the promotion of any_iterator from the Boost.Range internals into the Boost.Iterator library with Dave Abrahams. We both think that this would be useful. I have started implementing test cases to cover the additional use-cases that are not currently tested as part of Boost.Range. I shall then write appropriate documentation before any_iterator can then be reviewed by Dave before the final promotion to the public interface. I wanted to let everyone know the intent, so to enable decisions with-respect to using the existing non-public implementation.
Jeff
Regards, Neil Groves
original subject was: Re: [Boost-users] offlist - Re: [iterator] Problems with iterator_facade and const-qualification On May 15, 2011, at 5:16 PM, Neil Groves wrote:
[…] I have discussed the promotion of any_iterator from the Boost.Range internals into the Boost.Iterator library with Dave Abrahams. We both think that this would be useful. I have started implementing test cases to cover the additional use-cases that are not currently tested as part of Boost.Range. I shall then write appropriate documentation before any_iterator can then be reviewed by Dave before the final promotion to the public interface.
I wanted to let everyone know the intent, so to enable decisions with-respect to using the existing non-public implementation.
I was recently reminded of this and went looking for it in boost 1.49, but see no sign of it there (outside the existing range_detail version), nor in boost svn trunk. Anything I can do to help make this happen?
participants (4)
-
Dave Abrahams -
Jeff Flinn -
Kim Barrett -
Neil Groves