Thomas Witt <witt@acm.org> writes:
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.
Well, of course it wouldn't be a valid iterator. transform_iterator<derived_is<whatever>, ... > // using named param syntax isn't a valid iterator by itself.
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.
Yes, I was only talking about the capability -- not the means for getting it -- and saying why we need to do _something_.
But you know what you _don't_ like ;-)
Yep. I just try to be unhelpfull in a sophisticated way ;-).
Ever the urbane sophisticate, ain'tcha?
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.
So you don't mean DRs. That's a whole other ball-o'-wax.
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.
I honestly don't know. I think it's quite possible that we never distinguished the use of policies in the old design from the problems caused by not using CRTP.
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
Well, at least we agree there's a real problem. -- Dave Abrahams Boost Consulting www.boost-consulting.com