Re: [boost] Re: Iterator Adaptor Poll

From: David Abrahams (dave_at_[hidden])
Date: 2002-07-28 18:59:55

From: "Thomas Witt" <witt_at_[hidden]>

> What I was referring to was that I think that the current design is at
its
> limits if more complex policies are used. When trying to overcome the
current
> problems I realized that the current design is really good for simple
> applications. To be more precise for those where the policies do not have
to
> maintain state.

Yes, we agree that it gets cumbersome when the policies end up maintaining
state. The only real reason that the policies should maintain state is that
so many useful defaults come from the Base type. The "easy fix" is to
replace Base with State, and allow an optional "Base extractor" parameter
which defaults to an identity function object. There may exist more-elegant
fixes, of course.

> As soon as the policies have to maintain state the line between Policy
Adaptor
> and Adapter/LeanIterator gets blurred.

It's really hard to carry on this discussion without a definition of your
Adapter/LeanIterator concepts.

> You have two options move the state in
> the adapted class or in the policies class.
> When doing the first it is more like Policy Adaptor but most of the time
you
> will have to introduce two new classes. In the second case you only have
one
> new class but its not really a policies class as
default_iterator_policies
> is. I think that there is no clear distinction between both concepts it
> depends on the way you look at it.

I have only a vague sense of what you're saying. Code examples help.

> I would not say so either. But I think that a policies concept that fixes
> these problems is closer to Adapter/LeanIterator than the current one.

It's hard to say without seeing more details. There are lots of viable
approaches, though. Have you thought about using a GenVoca arrangement?

> > That's true. It relies on the convention that the iterator's users are
only
> > touching the interface of the Iterator concept, and not the other
member
> > functions (policies(), base()).
>
> The short answer is actually a question: If convention is the right
solution,
> why is "private" a keyword? Seriously I know there are scenarios where
> anything but convention would be an overkill. I just think this is not
true
> for iterator_adaptor.

I'm not claiming that it's the right solution. However, at least read-only
access to the state is often useful, and I wouldn't want to prohibit it.

> > > This
> > > leads to no end of problems regarding comparison and const/non-const
> > > interoperability.
> >
> > Really? No end? Please illustrate a few, since they are so plentiful
;-)
>
> Ok maybe I was exaggerating a bit, but with the current design it is
> impossible to implement a cycle or joining iterator that has natural
> const/non-const interaction.

Because you end up using a different type for the policies class in the
const version?

> A problem that can not be solved is a kind of a
> no end thing, isn't it?

Well, I wouldn't attempt to downplay it. That does sound significant.

-Dave