From: Thomas Witt (witt_at_[hidden])
Date: 2005-02-17 17:19:54
David Abrahams wrote:
> Thomas Witt <witt_at_[hidden]> writes:
>>I can see this being usefull, but deriving from an iterator is such a
>>no-no that creating a optonally derivable iterator somehow seems wrong
> What you're saying is that giving people a way to do it correctly will
> encourage them to do it incorrectly, and therefore we shouldn't?
What I was trying to say was that I'd prefer to see a solution that
provides the desired functionality without having the user derive from
what otherwise is a valid iterator.
>>We could add another level of indirection and introduce
>>xxx_iterator_base<Derived, ...> types. And no I don't consider this
>>a very bright idea either.
> The problem is that the previous version of the library using the
> policy adaptor pattern _had_ this capability, because you could grab
> the policies class that each adaptor published as part of its public
> interface, and derive a new policies class from it.
Well that's actually more like deriving from xxx_iterator_base.
> But you know what you _don't_ like ;-)
Yep. I just try to be unhelpfull in a sophisticated way ;-).
>>This directly relates to what I said before. The whole area of
>>iterator categories is so murky currently. IIRC there are
> DRs? Do you mean against C++03 iterators in the standard?
I am mostly referring to iterator_categories here. IIRC not all issues
that came up during the iterator adaptor discussions are resolved yet.
> Well, maybe we need to return to policy adaptors, with a hybrid
> class my_iterator
> : public iterator_facade<my_iterator, my_policies>
> // c'tors here
Wasn't that one of the original design ideas that was ruled out due to
... ? If only I could remember what the rationale was.
> But ultimately, I think we do need some way to allow users to
> conveniently refine the existing adaptors, and we need to do it
> *before* template aliases show up in their compilers!
-- Thomas Witt witt_at_[hidden]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk