Boost logo

Boost :

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


> I agree that these are illegal. I was talking about the operator
> templates, with an eye towards establishing a private base class
> iterator_adaptor<> which had a public mutable base() function; the
> 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
> 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?


Boost list run by bdawes at, gregod at, cpdaniel at, john at