$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Ed Brey (edbrey_at_[hidden])
Date: 2001-07-26 13:14:50
From: "Jeremy Siek" <jsiek_at_[hidden]>
> On Thu, 26 Jul 2001, Ed Brey wrote:
> > From: "Jeremy Siek" <jsiek_at_[hidden]>
> > >
> > > template <class Range>
> > > void sort_heap(Range& range)
> > > {
> > > std::sort_heap(range.begin(), range.end());
> > > }
> > >
> >
> > When will the reference ever need to be non-const? All the
underlying
> > algorithms take iterators by value, and hence leave them untouched.
>
> The above sort_heap() function is an example when the reference needs
to
> be non-const.
>
> Suppose we are using the above sort_heap with std::vector.
>
> std::vector<int> x(n);
> ...
> sort_heap(x);
>
> The elements in the vector will be modified by the algorithm, so we
need
> mutable iterators. Therefore, the calls to range.begin() and
range.end()
> better return iterator and not const_iterator. Therefore, we have to
pass
> by non-const reference in order to get the mutable iterator.
I think I see what you are getting at now. If I understanding
correctly, you have this mapping in mind:
range -> iterator, iterator
range const -> const_iterator, const_iterator
I propose using a different mapping instead:
range -> iterator, iterator
range const -> iterator const, iterator const
const_range -> const_iterator, const_iterator
const_range const -> const_iterator const, const_iterator const
Not only does having a range and a const_range solve the
pass-by-non-const-reference problem, it also gives ranges the full
expressive power regarding constness that iterators currently enjoy.