Re: Iterator adaptor documentation

From: witt_ive (witt_at_[hidden])
Date: 2002-01-30 16:30:44

Dave,

> 
> I agree that these are illegal. I was talking about the operator 
function
> templates, with an eye towards establishing a private base class 
for
> iterator_adaptor<> which had a public mutable base() function; the 
operators
> would need to pass the base class to the policies. To do that, 
they would
> need to be friends. I think the best we can do right now is to fix 
the
> documentation. Would you like to submit a patch?

the patch I would like to submit would add a description off the 
adaptor/policies interaction, but for now I don't feel capable of 
describing the interaction.

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?).

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.

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. 

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).

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.

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?

Thomas