Re: [boost] Re: Re: Re: rtl (Range Template Library)

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

copy(filtered(container),target);

but important when you do something like

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

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.

Yours,
Martin

-- 
Dr. Martin Weiser            Zuse Institute Berlin
weiser_at_[hidden]                Scientific Computing
http://www.zib.de/weiser     Numerical Analysis and Modelling