Re: [boost] Re: Iterator adaptor documentation

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-02-09 09:35:09

----- Original Message -----
From: "witt_ive" <witt_at_[hidden]>

> The longer I think about it the more unhappy I feel with the current
> design. I tried looking up the history of the current design in
> yahoogroups but I was only partially successfull(It must not be that
> diffcult/awkward to handle, must it?), so if I am missing an
> important point take my apologies.
>
> I could have started like this:
>
> The iterator_adaptor provides the full interface while it dispatches
> the base_iterator handling to its policies object. Therefore it
> passes itself to its policy object. The policy object then extracts
> the base_iterator from the iterator_adaptor in order to
> dereference/modify it (This sounds broken, doesn't it?).

Not to me. And, BTW, the policies object doesn't have to extract the base
object; it can do anything that's appropriate.

> The reason for not directly passing the base iterator to the policy
> object is the handling of iterator_adaptor comparison with statefull
> policies. In order to perform the comparison the policy object of
> the iterator_adaptor responsible for the comparison extracts the
> policy object from the second argument iterator_adaptor.

There are other reasons. If you look back at the CVS state, you'll see that
the old policies interface which took base objects as arguments was much
messier because there was no way to deduce the return types of dereference()
and distance() from the types of the base objects alone. It's much cleaner
to pass the entire iterator_adaptor object.

> When thinking about all this the following came to my mind:
>
> If there is a one to one mapping iterator_adaptor<->policy object,
> why does the policy not store a reference to the adaptor instead of
> passing it around again and again.

That would double the size of most iterator adaptors.

> Why is the comparison of the policies done by the policies themself.
> Couldn't it be perfectly handled in the iterator_adaptor
> operator==(it has to be friend anyway).

Most often there's no need to compare policies. The policies objects know
what types they are, so there's no need to spread the comparison logic
around. I don't see how this would help anyone.

> Comparing the policy objects would have the nice impact that
> iterator interoperability might be made more flexible(I have not
> checked this in the code by now). The new rule would be:
> Adapted iterators are called interoperable if they share the same
> Category, and Distance parameters and an operator== is defined for
> their Policies parameters.

It would be easy to lift all restrictions on the policies for
interoperability. I don't see any point in requiring operator== on the
policies.

> The above would be needed for what any policy that has to store
> base_iterators. Logically policy<base> and policy<const_base> are
> perfectly interoperable with regard to comparison. In the current
> design they are not.
>
> Does all this make sense?

Not all of it, but I understand the desire to be able to compare iterators
built on related policies parameterized on different types. The real problem
here, IMO, is that the notion of state in policies objects is really a hack
(or, maybe, not the "right" hack ;^)). It would be better if the storage of
auxilliary state information could be separated from  the policies somehow.
However, all of the design alternatives I can imagine for accomplishing that
lead to one or another unacceptable problems.

-Dave