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
> limits if more complex policies are used. When trying to overcome the
> 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
> 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
> and Adapter/LeanIterator gets blurred.
It's really hard to carry on this discussion without a definition of your
> 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
> will have to introduce two new classes. In the second case you only have
> new class but its not really a policies class as
> 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
> > touching the interface of the Iterator concept, and not the other
> > functions (policies(), base()).
> The short answer is actually a question: If convention is the right
> 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
> 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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk