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>
for_each(InputSequence const& seq, UnaryFunction const& f)
> The whole area needs some experiment and practical
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.
> 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.).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk