Boost logo

Boost :

From: Martin Weiser (weiser_at_[hidden])
Date: 2003-11-21 03:46:04

On Freitag, 21. November 2003 01:08, John Torjo wrote:
> >>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
> Basically, I see ranges that reference a container as actually refering
> to container.begin() and container.end()

Basically, yes. But the semantics is different from *storing* iterators in
the range object and forgetting the container behind. Think of iterator
invalidation issues when the container is manipulated. Of course this is
irrelevant when constructing temporary ranges, such as


but important when you do something like

view_type<...> filter_view(container);
// manipulate container here, invalidating all iterators

Thus, ranges should provide a begin/end pair of iterators, but should not
be required to be implemented in terms of a pair of iterators. That's the
whole point.

> You do make a strong point for "views" - such ranges should never be
> reset. In other words, they are initialized in their constructor.
> Afterwards, they cannot be changed, just traversed. Right?

Yes, essentially. Citing you:

On Thursday 20. November 2003 19:11, John Torjo wrote:
> AlisdairM wrote:
> > i/ Containers should automatically be valid ranges. Therefore it is
> Containers are automatically valid ranges, but only for the purpose of
> algorithms. Indeed you make a valid point: we need two separate
> definitions: one for the concept of range taken by an algorithm, and
> one for our range traversal class. Right?

Right. Ranges taken by an algorithm should not be required to provide
operator++(), operator bool(). Instead, standard containers and views
which try to mimick the container interface should be directly usable.

The easy and syntactically pleasing range traversal is a different topic
in it's own right.

> > 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
> I'm not sure I follow...

Not that important ;) Referencing containers enables some fancy
functionality you cannot have with storing an iterator pair. The point
is, there are legitimate uses of ranges/views which are *not* implemented
as a pair of iterators.


Dr. Martin Weiser            Zuse Institute Berlin
weiser_at_[hidden]                Scientific Computing     Numerical Analysis and Modelling

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