Dave, David Abrahams wrote:
Thomas Witt <witt@acm.org> 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 to me.
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 outstanding DRs
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 approach:
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!
Agreed Thomas -- Thomas Witt witt@acm.org