Re: [boost] [range] Is it conceivable to have it extended?

Subject: Re: [boost] [range] Is it conceivable to have it extended?
From: Nathan Ridge (zeratul976_at_[hidden])
Date: 2014-07-13 22:22:45

> boost::iterator_range is a great concept/class but it does not seem to
> play efficiently with certain input sequences and seem to be too strong
> a requirement for certain algorithms. I have an old-fashioned C string
> in mind (I am sure there are other examples) and traversing algorithms.
>
> When I tried deploying boost::iterator_range for string-to-int
> conversion purposes, I quickly realized that I was traversing the string
> twice -- first to find the end and second to do the work.
>
> What I think is missing is the "parent" concept of a "sequence". Say,
>
> template<iterator_type, sentry_type>
> struct sequence
> {
> iterator_type begin();
> sentry_type sentry();
> };
>
> Then "range" would implement and refine the "sequence" concept by
>
> template<iterator_type>
> struct range : sequence<iterator_type, iterator_type>
> {
> iterator_type begin();
> iterator_type end();
> sentry_type sentry() { return end; }
> }
>
> I.e., as "range" implements/is the "sequence", the boost::iterator_range
> will have one additional "useless" sentry() method.
>
> That way all the old code (using and/or needing end()) would still work
> but traversing algorithms might gradually adapt to only require
> "sequences" instead of "ranges":
>
> template<typename Iterator, typename Sentry, typename Function>
> Function
> for_each(Iterator beg, Sentry sentry, Function fun)
> {
> for (; beg != sentry; ++beg) fun(*beg);
> return fun;
> }
>
> That means that now all "open-ended" (with no known "end") "ranges"
> (they are not even "ranges" in the strict meaning of the word but rather
> "sequences") can be handled efficiently.
>
> I ended up having such an "extended" range in Boost.Convert (to handle C
> string traversals efficiently) but I hate having/maintaining the code
> and much prefer the standard solution.

Eric Niebler ran into the same problem and came up with a solution
more or less along the same lines: an Iterable concept which
generalizes a Range, which has begin and end iterators of potentially
different types [1].

My understanding is that Eric plans to present a library implementing
his approach at the next C++ standards committee meeting in November.

Regards,
Nate

[1] http://ericniebler.com/2014/02/21/introducing-iterables/