On Tue, Oct 30, 2012 at 3:08 AM, David Kimmel
Whoa fast responses!
I like make_iterator_range and sliced but they don't quite seem to do it. Good point on the std::distance. No need to add a new make_iterator_range - I may consider rethinking my approach or just leaving as is. Thanks everyone!
make_iterator_range is perfectly capable of meeting your expressed requirements. I have done this many times, I'm not hypothesising. Please see my original post. You just use boost::next to advance one of the iterators that define the range. See http://www.boost.org/doc/libs/1_51_0/libs/utility/utility.htm While respecting Thorsten's opinion and the wish to provide convenience functions to our users, I'm not keen on introducing make_iterator_range (iterator, size_type) it seems like an unnecessary addition that would not significantly improve syntax. It would also duplicate the logic behind boost::next within non-member functions in Boost.Range like make_iterator_range. I prefer orthogonal solutions and composition to duplication of the advance logic. Neil Groves