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
struct sequence
{
iterator_type begin();
sentry_type sentry();
};
Then "range" would implement and refine the "sequence" concept by
template
struct range : sequence
{
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
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?
Vladimir.
