Boost logo

Boost :

From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2007-10-29 13:34:08

On 10/29/07, Thorsten Ottosen <thorsten.ottosen_at_[hidden]> wrote:
> Daniel Walker skrev:
> > On 10/29/07, Thorsten Ottosen <thorsten.ottosen_at_[hidden]> wrote:
> >> shunsuke skrev:
> >>> Thorsten Ottosen wrote:
> >>>> You would rather see range_mutable_iterator and range_const_iterator there?
> >>> Yes.
> >>>
> >>> I've found an interesting quote in doc/boost_range.html:
> >>>
> >>> The special metafunctions range_result_iterator and range_reverse_result_iterator
> >>> are not part of any Range concept,
> >>>
> >>> You knew it.
> >> Well, those docs are so old now, I'm not sure they should be take too
> >> seriously.
> >>
> >> The formulation I'm leaning towards in the new docs are the following:
> >>
> >> Single Pass Range:
> >>
> >> types:
> >>
> >> range_iterator<T>::type
> >> range_iterator<const T>::type
> >
> > What if you have a non-const range of const_iterators? It seems like
> > you still need range_const_iterator.
> Why?

I was thinking of a scenario where mutability and constness don't
correlate - for example, when an immutable range is not const.
However, after taking a second glance at the old docs, I'm not sure
this applies to ranges. The return type of begin(r) has always been
tied to the constness of r, which is confusing for a non-const
immutable range. So, you're suggesting to stop using types to
distinguish the mutability of ranges? I think I get it, yeah, that
could clean things up.

So, if the range is made up of const_iterators,
range_iterator<T>::type is const_iterator, and if the range is made up
of mutable iterators, range_iterator<T>::type is iterator. begin(r)
always returns range_iterator<T>::type: range_const_iterator<T>::type
is no longer needed. It does simplify matters.


Boost list run by bdawes at, gregod at, cpdaniel at, john at