Boost logo

Boost :

Subject: [boost] [range] Is it conceivable to have it extended?
From: Vladimir Batov (Vladimir.Batov_at_[hidden])
Date: 2014-07-13 17:10:23

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

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>
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.

Any suggestions?


Boost list run by bdawes at, gregod at, cpdaniel at, john at