Boost logo

Boost :

From: Richard Peters (R.A.Peters_at_[hidden])
Date: 2002-02-12 10:50:59


I wanted to build the value_range on top of iterator_range, because then
there would be little difference in a range of say [0, 5) and a range of [0,
5) where you can iterate through.
The problem of that is that comparing values of the range have different
meaning. When you want the size for instance, you have to compare the begin
and the end. If the value_range is built on top of the range_iterator, you
would compare the value held by the first iterator with the value held by
the second iterator. If it holds normal iterators, you want to compare the
iterators themselves, not the values held by them. I see now that this is a
big problem, and I come up with something for the other approach.
I've cleared up my previous files, this is what I programmed today:
http://groups.yahoo.com/group/boost/files/range/range.hpp
http://groups.yahoo.com/group/boost/files/range/range_test.cpp
I also made an iterator_range.hpp, but that one isn't ready and it's too
late to continue today...

----- Original Message -----
From: "David Abrahams" <david.abrahams_at_[hidden]>

> Fine; iterator_ranges are more important to what you'd like the STL to be.
> BTW, you will have overloading problems if you try to define versions of
> those functions which work with ranges because some of the functions
already
> take an optional predicate or UnaryFunction object.

I see two ways of fixing that:
- Use typetraits, looks like this or so:
We want this:
function(iterator i1, iterator i2, predicate p)
function(iterator i1, iterator i2)
function(range r, predicate p)
We code this:
function(type t1, type t2)
{
  detail_function(t1, t2, is_range_type<t1>);
}
detail_function(iterator i1, iterator i2, false_type)
detail_function(range r, predicate p, true_type)
this works rigth?
- Make use of some sort of specialization
template<class Iterator> function(Iterator i1, Iterator i2)
template<class Iterator> function(iterator_range<Iterator> r, predicate p)
this works too right?
Actually, for <algorithm> this is only of interest when the iterator_range
would be made part of the c++ standard. For now, the functions live in
different namespaces.

> Woudn't it make sense to re-evaluate your position resorting to such
extreme
> measures?

Well, I've done that now :)

---
Richard Peters
Eindhoven University of Technology

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk