Re: [boost] reorder_iterator : iterator_adaptor

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-11-24 15:35:04

----- Original Message -----
From: "Toon Knapen" <toon.knapen_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Saturday, November 24, 2001 1:29 PM
Subject: Re: [boost] reorder_iterator : iterator_adaptor

> > Not at all: you're storing two iterators in the adaptor; I'm storing two
> > iterators. In fact, my latest suggestion stores the same iterators
you're
> > storing, in the same places. There's simply no need to move the Base
> > iterator, since you can implement dereference() in the Policies class
as:
> >
> >     template <class IteratorAdaptor>
> >     typename IteratorAdaptor::reference
> >     dereference(const IteratorAdaptor& x) const
> >     { return *(*(x.policies().order_it_) + x.base()); }
>
>
> OK. So I guess you meant in :
> " BTW, in the above design, the iterator in the Policies class is never
> changed unless the iterator is assigned to .. "
> that the _Base_ is never changed to traverse the sequence.

Sorry; there are 3 designs here. My original (which you never saw: the base
object held the iterator over permutation indices and the policies object
held the iterator to the base of the sequence to be permuted), your design,
and the hybrid design I'm now advocating. In the sentence you quote, I was
referring to the first of these. In the hybrid design, the Base doesn't need
to change.

> So I guess we converge to the scheme were the Base is the actual random
> iterator and which is the second argument to the
> make_permutation_iterator such that the past-the-end can be specified by
> means of the first argument

I don't see why the argument order to the generator(s) is important, but
yes, I always thought that past-the-end should be determined by a position
in the sequence of permutation indices.

FWIW, still think "permutation iterator" is still a better name for this
beast, even though it can be used to do other kinds of shuffled traversals.

-Dave