RE: [boost] iterator ranges; eliminating private member functions

From: Aleksey Gurtovoy (alexy_at_[hidden])
Date: 2001-11-05 03:54:50

Dave Harris wrote:
> I wouldn't suggest that. Some algorithms, such as binary 
> search, seem to fit iterator pairs quite well. However, 
> there are many algorithms where a single range object 
> makes sense and I think it should be preferred for them.

For all algorithms that take an iterator pair (i.e. two iterator parameters
that designate a single input/forward/etc. sequence) it makes sense and is
very practical to have a version (wrapper) that takes a single sequence
argument - a model of Sequence concept, e.g.

template<typename InputSequence, typename UnaryFunction>
inline
UnaryFunction
for_each(InputSequence const& seq, UnaryFunction const& f)
{
    return std::for_each(
        boost::begin(seq)
      , boost::end(seq)
      , f
      );
}

> The whole area needs some experiment and practical 
> experience. 

As I mentioned before (http://groups.yahoo.com/group/boost/message/15355),
here at work we _do_ have practical experience with the approach outlined
above and in the past messages on the topic in this list. Simple as they
might seem, these wrappers + (of course) iterator_range<> class (+
any_iterator<> template) worth every second of time we've put in them. I
just wish I had time to get the library to the state suitable for a formal
review, so everyone else could benefit from it too.

> 
> The way I look at it, much of the STL is based around the 
> concept of a sequence, and it is good design to represent 
> fundamental concepts explicitly. 

Agree completely.

> A pair of iterators is not a very explicit representation; it 
> is at the wrong level of abstraction. Stroustrup says more about the 
> problems this causes in C++PL, $18.3.1.

It's more about the algorithms that require two separate iterators as their
arguments instead of taking a single Sequence parameter. There is nothing
wrong with representation of sequences as pairs of iterators itself (in
fact, I would argue that this is probably the most practical model, at least
in C++), as long as that representation is explicitly supported by the
library interface (e.g. you should be able to construct a std::vector from
an input sequence, etc.).

Aleksey