On Tue, Oct 30, 2012 at 3:08 AM, David Kimmel <davidwkimmel@gmail.com> wrote:
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