[boost] Re: rtl (Range Template Library)

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2003-11-19 00:46:34

Hi John

"John Torjo" <john.lists_at_[hidden]> wrote in message
news:00f601c3aed8$ce4bf800$1a01a8c0_at_john1...
> Dear boosters,
>
> Matt Wilson and me have developed the rtl (Range template library), in
order
> to ease working with iterators/container.

If I had known that you intended to support algorithms, I would have
contacted you sooner.

[snip]
> The rtl (Range Template Library) is meant to ease working with iterators
and
> containers.
> The purpose of RTL is to eliminate redundant code.
> Example:
> Instead of the redundant:
> std::copy( cont.begin(), const.end(), wherever);
> you could simply write:
> rng::copy( cont, wherever);
>
> Of course, real code is much more complicated, so using rtl will usually
> save you quite
> a few keystrokes, and the code will be more readable.

have you looked at the sequence_algo dir in the sandbox? For quite some time
there have been container algorithms in there. This was the main motivation
for
having container traits.

> The rtl consists of the following big parts:
> 1. range classes
> 2. range algorithms
> 3. range adaptors
>
> 1. range classes
> A range is roughly a pair of iterators.
>
> A range class exposes the following:
> * the begin() and end() functions.
>   There is only one begin() function and one end() function
>   (no different const/non-const versions).
> * typedefs for 'iterator', 'value_type', 'reference', 'pointer'.
>   These are taken from the underlying iterator.
>   There's no const_iterator, const_reference, etc, since a range
>   is just a pair of iterators. So, if the iterator is const,
>   'iterator', 'value_type', 'reference' and 'pointer' will reflect that.

Please see Pavol's iterator_range class that was bundled with his string
algorithms.
You might won't to read some of the threads on our discussion of a range
class.

> A range can be used in STL algorithms (shown below), or you can
> decide to manually walk through it. Walking through a range is a blast.
> Example:
>
> typedef std::vector<int> array;
> array v;
> // ... fill it
> crange<const array> r(v);
> while( r)
>     std::cout << *r++ << std::endl;

This seems like something that could be useful. Recently Eric presented his
FOR_EACH macro
which made traversing easy. It seems that this class is a bit like an
iterator, maybe it could be
a range_iterator<> on its own? (I haven't looked at the code, but I assume
it's possible to pass two iterator's as argument to the constructor).

>
> You can also manually set the beginning and end of a range:
> // ignore first and last 5 elements
> r.begin( v.begin() + 5);
> r.end( v.end() - 5);
> while( r)
>     std::cout << *r++ << std::endl;

why not just make a new one providing the smaller range as arguments to the
constructor?

> The basic range classes are:
> template< class container> class crange;
> template< class iterator> class irange;
>
> Examples of usage:
> crange< const container> r(...); // const range
> crange< container> nr( ...); // non-const range
> irange< iterator_type> ir(...); // from iterator
>
> A range can be created from a container/const container/2 iterators.
> crange< container> r( cont); // const or non-const container
> crange< container> r( beg, end); // two iterators
>
> A range preserves the underlying iterator properties.

what is the benefit of crange? AFAICT, irange is all we need.

> 2. range algorithms
> All STL algorithms are implemented for ranges as well.
> (note: currently we have not implemented mismatch and partial_sort_copy).
>
> For the purpose of ALL range algorithms, a container IS a range.
> Therefore, the following is possible:
>
> typedef std::list<int> array;
> array l;
> l.resize( 50);
> rng::generate( l, next() ); // next() is a functor
> rng::reverse( l);
> // prints the given list to console
> rng::copy( l, std::ostream_iterator<int>(std::cout," ") );

there is no major difference between this and the stuff in the sandbox. One
thing
might be that if the container traits (soon to be rename collection traits)
is used, we can use ordinary arrays too with the algorithms.

> We are also still debating the precise definition of the Range Concept,
> and anticipate that your opinions will help cement the matter. We're
hoping
> that the range concept can be applied to other languages, and are
envisaging
> looking at C#(.NET) and D at a future time.

As mentioned, there has already been some discussions regarding this. In the
files section, one can find
Jeremy's collection cencept which seems like the right thing (without
swap())

best regards

Thorsten