Re: [boost] reorder_iterator : iterator_adaptor

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-11-24 13:21:05

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

> > BTW, in the above design, the iterator in the Policies class is never
> > changed unless the iterator is assigned to. A hybrid scheme wherein the
Base
> > iterator is never changed, but the Policies class embeds an iterator
over
> > the permutation idices might be the simplest of all,
>
> but this will increase the memory footprint since you need to keep track
> of the index you're at (so that you can use this to find the right
> index in the reorder sequence in the derefence function)

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()); }

> > since you can take
> > advantage of more compile-time defaults.
> which specifically are you thinking of ?

The mechanisms which compute the default value_type, reference, and pointer
from the Base iterator type. When the Base object iterates over permutation
indices, you don't get any of that.

-Dave