[boost] Re: rtl (Range Template Library)

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2003-11-19 04:41:59

"Matthew Wilson" <stlsoft_at_[hidden]> wrote in message
news:bpfbeq$52p$1_at_sea.gmane.org...
> > > 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?
>
> He he. This is one of the areas about which John and I are still in
debate.
> I'm in favour of the simplest-is-best, but John favours the resettable
> ranges. John's got more "hand", though, since he's done most of the work.

In the rare cases where it is needed, one can easily copy both iterators.
What if the iterators are not random access? what if they are not
bidirectional?

> > what is the benefit of crange? AFAICT, irange is all we need.
>
> We need to distinguish between the range concept, and a particular
> implementation. As far as I'm concerned a range is simply something that
> fits the expression:
>
>   for(; r; ++r)
>   {
>     *r; // Do something with the element at the current enumeration point.
>   }
>
> Everything else is implementation.

ok. seems to me it's more like a new iterator, a range iterator.

> Having said that, John's done a pretty fine first implementation, based
> strongly around interroperability with Boost, so any fat that's got in
there
> is more than forgiveable. I plan, eventually, to do an STLSoft
> implementation, which will probably be more minimalistic, since I'm
lazier.
> :)

on the contrary, making some small is the hard work.

> Another important feature that, for all we STL-fans, is easy to overlook
is
> that ranges do not need to be based on any "real" nature (in respect of
> existing in a container, or in the range of an iterator pair). In fact the
> first range I wrote was integral_range, which looks roughly like:
>
> template <typename T>
> class integral_range
> {
> public:
>     typedef T                           value_type;
>
> public:
>     integral_range(value_type first, value_type last, value_type increment
=
> +1);
>
> private:
>     struct boolean { int i; };
> public:
>     operator int boolean::*() const;
>
>     value_type operator *() const;
>     class_type &operator ++();
>
>     bool operator ==(class_type const &rhs) const
>     bool operator !=(class_type const &rhs) const
>
> // Members
> private:
>     value_type  m_position;
>     value_type  m_last;
>     value_type  m_increment;
> };
>
> Anyway, I'm sure you get the idea. :)

this would have a bit the functionality of counting_iterator, right?
your concept seems a bit like iterators in Java

while( c.hasNext() )
   iterator i = c.next(); ...

without the iterators, which could be nice when you couldn't use an
algorithm.
Eg.

typedef vector<int> vector_t;
vector_t v;
...
range_iterator<  vector_t > i( v );
while( i )
{
    foo( *i );
    ++i;
}

or if Pavol's iterator_range got a few extensions it could do the same.
About the range stuff, the is really the thing about open, closed and
half_open ranges
which should be dealt with.

> > In the
> > files section, one can find
> > Jeremy's collection cencept which seems like the right thing (without
> > swap())
>
> Sounds interesting. I'd like to look into it. Any chance of the right url,
> for a total Boost neophyte?

just read the Collection Concept thread.

best regards

Thorsten