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

From: AlisdairM (alisdair.meredith_at_[hidden])
Date: 2003-11-19 05:16:40

John Torjo <john.lists_at_[hidden]> wrote in
news:3FBBFFD9.4000601_at_[hidden]: 

> Now that I think about it, a range concept does not even need to be so
> complicated. As explained above (in the original message):
> - a range is a pair of iterators
> - it has typedefs for value_type,pointer,reference
>    (no const_pointer,no const_reference)
> - it's got begin() and end()
> - it's got an operator bool() that returns true if the
>    range is non-empty.

I have been on the verge of my own 'range' library for a while now, and 
have finally freed up enough time to get started on it.  I will certainly 
look into your proposal, but I'm not entirely happy with the formulation 
above.

In particular, range as a concept should not specify that a range is a pair 
of iterators.  This will be a common implementation, but should not be the 
only one.  Some motivating examples:

i/  Containers should automatically be valid ranges.  Therefore it is 
reasonable to expect a range to return iterators from begin()/end(), but 
they may be implicit rather than data.

ii/ ranges will need classifying similar to iterators, eg forward traversal 
ranges, random access ranges.  A forward range might be expressed by a 
single iterator and a terminate condition.  (eg istream_range)  Default 
constructing iterators to act as end() sentries always struct me as odd, so 
I would like to take this requirement out of an initial pass.

Likewise, the test for empty ranges should be to call an empty() function.  
This way standard containers continue to make conforming ranges.

The other part of the range library I was planning was range_adaptors along 
the lines of iterator adaptors.  With transform_range and filter_range, you 
can cut down on the number of algorithms that actually need supporting (eg. 
filter_range reduces the need for many [but not all] _if algorithms)

Finally, as pointed out elsewhere, lightweight ranges make ideal return 
values from functions.  eg: a map might have keys/values member functions 
returning some sort of transform_range, or following container_traits lead 
these could even be free functions.

I am keen to look into your actual proposal asap, but probably not till 
weekend :¬ (

AlisdairM