From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2003-11-02 23:49:14
"Pavol Droba" <droba_at_[hidden]> wrote in message
> On Sun, Nov 02, 2003 at 02:48:26AM -0600, Aleksey Gurtovoy wrote:
> > David Abrahams wrote:
> > > "Thorsten Ottosen" <nesotto_at_[hidden]> writes:
> > > > And for iterator_range, it's kind of double information when you
> > > > write
> > > >
> > > > iterator_range< some_iterator >
> > > >
> > > > instead of
> > > >
> > > > range< some_iterator >.
> > >
> > > IMO "range" is too short and general a name to be reserved in boost
> > > for half-open-range-of-iterators.
> > I am with Dave here. FWIW, our iterator range class at work is called,
> > 'iterator_range' :).
> This seem very convincing :) I will keep the name "iterator_range" and
> functions will be ranamed to follow.
that's a quick decision :-)
I'm still not convinced that we need more than one range class for anything.
> It should only be called "range" if it's meant to work on ranges of
> non-iterators. But then, you should call it half_open_range ;-)
I don't agree. The current interface seems compatible with any type of
template< typename T >
T begin() const;
T end() const;
T size() const;
bool empty() const;
AFAICT, only size() needs to be specialized for integers which should be
easy using typetraits. So the same range class can easily support
both iterators and integers.
Moreover, the standard uses half-open ranges of the type
where 'begin' is included and 'end' is not. If the argument for not using
the name range for the class is that many different types of ranges exist,
we should consider if that is a good thing with these many ranges. IMO, it
is not a good thing because all the ranges can be used to describe
[begin,end] = [begin, end + 1 )
(begin, end) = [begin +1, end )
(begin, end] = [begin + 1, end + 1 )
To me it seems that it shall only be necessary with one type of range.
Bringing more into the picture will only bring confusion.
Aleksey, what do you use the different range types to at your work?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk