From: Martin Weiser (weiser_at_[hidden])
Date: 2003-11-20 06:03:37
On Donnerstag, 20. November 2003 10:09, AlisdairM wrote:
> John Torjo <john.lists_at_[hidden]> wrote in
> Lots to think about, but I'll just come back on one specific point that
> I think I should have explained better ;¬ )
> > I don't agree here. A forward range still has two iterators.
> > The fact that you don't have to deal with them directly, that's the
> > added bonus ;)
> >>> [istream_iterator example]
> > I'm not sure I understand. The way we see ranges is still as a pair
> > of iterators. There still must be a begin() and an end(), for us to
> > have a range. How you implement end() internally it's still up to you
> > (the implementor of the iterator class).
> > You should note the fact that if we take out the requirement of a
> > range being a pair of iterators, how could you use it in algorithms?
> The idea I am pushing for here is that ranges ARE NOT pairs of
> iterators. Rather, a pair of iterators happens to make a good
> representation of a range, but may not be the only one.
I'd like to second this idea, though with a different motivation:
What about "ranges" that reference a container or another range instead of
containing two iterators? Ranges of this kind are also known as "views"
and can be quite useful in some situations. The main difference is
iterator/range invalidation and ownership management, and becomes
relevant once you store ranges for using them later on. By requiring that
a range is defined by two iterators views would be left out, even though
they come quite close to my understanding of "range".
You might want to have a look at the (somewhat dated by now) view template
library at http://www.zib.de/weiser/vtl/ or its predecessor by Jon
Seymour at http://www.zeta.org.au/~jon/STL/views/doc/views.html.
-- Dr. Martin Weiser Zuse Institute Berlin weiser_at_[hidden] Scientific Computing http://www.zib.de/weiser Numerical Analysis and Modelling
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk