From: AlisdairM (alisdair.meredith_at_[hidden])
Date: 2003-11-19 05:16:40
John Torjo <john.lists_at_[hidden]> wrote in
> 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
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 :¬ (
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk