Re: [boost] Ranges

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-02-09 16:03:53

----- Original Message -----
From: "Richard Peters" <R.A.Peters_at_[hidden]>

> see above, my humble opinion is that you iterate over values, you do that
> with iterators. btw, when you do something like copy(from, to),
*to.begin()
> should be valid if you use functions like begin, end.

No argument there, but I don't see how it affects design choices for a
half_open_range.

> if you use an integer
> instead of counting_iterator<int>, that would not be possible AFAICS.

Uh, why not?

std::copy(make_counting_iterator(2), make_counting_iterator(7), dest) will
write 2,3,4,5,6 into the sequence starting at dest

> > > For iterators, you need a concept, so
> > > that you can for example make a counting_iterator, that still fits the
> > > criteria. For ranges, you just fill in the counting_iterator as
template
> > > parameter.
> >
> > I don't think that will do, either. What about a range of floats? float
> > doesn't fulfill the concept requirements for counting_iterator.
>
> hmm... yes that's right... I think however, that the aim of these ranges
> (half open ranges) is different than ranges of floats.

Your aim, AFAICS, is to make iterator ranges. Mine was to make generalized
half-open ranges. Since iterator ranges are just a subset of generalized
ranges, it seems like a win to shoot for the generalized model.

> Ranges of float could
> be made in many different ways, closed, open, half open, half closed. They
> might need a seperate set of classes, or we would have to think of a way
> making ranges be one of the other variants. I think however that that
would
> be too difficult.
> Making another iterator_adaptor (value_iterator?) that takes everything as
> value_type, could be a solution to get a half-open range of floats.

When people make ranges of ints and floats, they typically aren't interested
in iteration. Rather, they want to do things like intersection, join, tell
me whether a number is contained in the range, etc. However, many of those
operations can be useful with iterators as well.

> > > So I think range is a class, not a concept.
> >
> > I don't understand how you're making that conclusion. Could you spell
out
> > the reasoning in more detail?
>
> There is a single class, not a set of classes that have all the same
> operations, typedefs, etc. That single class would be usefull in all
cases,
> so there's no need for other classes. With iterators for example, there
are
> a lot of different classes, all having same operations, etc. So in that
> case, an iterator is a concept with a lot of models.

Unless you're planning on making a non-templated range class that covers a
single type, you have a set of classes with the same operations, typedefs,
etc. The fact that you think you can build a generalized model of range
doesn't make it useless to treat a range as a concept.

> > > 4 What operations should a range class support?
> > > All three support begin() and end(). [JSDA] and [DW] support functions
> > like
> > > contains() and find(). [JSDA] and [RP] support front(), back(),
size(),
> > > empty(). [RP] supports pop_front(), pop_back(), operators *, ++, --,
[],
> > +,
> > > +=. The operators in [RP] are provided to make the range handle like
its
> > > iterator begin().
> > > I doubt functions like contains() and find() should be in the range
> class,
> >
> > On what basis? I'm not neccessarily arguing, but contentions like this
> > should come with justification.
>
> I'm sorry for not explaining myself. I meant, such functions should maybe
> provided as seperate function, like the functions in <algorithm> aren't in
> containers, either.
> As I read it back now, I see that my wordings are a bit too offensive.
> English is not my native language, and I sometimes have difficulties
> explaining exactly what I mean. My appologies for this.

I'm not offended in the least, but I still don't see any reasoning behind
your conclusion.

-Dave