Thomas Witt <witt@acm.org> writes:
Dave, Thorsten,
David Abrahams wrote:
"Thorsten Ottosen" <nesotto@cs.auc.dk> writes: It has been pointed out that this sort of thing would be very much easier if, like iterator_facade and iterator_adaptor, all the specialized adapters could accept one more optional parameter that specifies the most-derived iterator class. I think that's a good idea, but I'm not sure how to do it without making the interface overly complicated. Ideas? I don't want to go back to the "bad old days" of named template parameters.
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?
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.
With respect to iterator lib maintenance. Me personally I don't feel confident in making changes as I don't have a good feeling on what is really needed or what the correct solution will be.
But you know what you _don't_ like ;-)
In fact, the way default types are calculated and specified in the iterators library is just too complicated and needs to be re-examined.
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?
and issues that where never really resolved. In general I do agree.
The whole iterators library needs some attention, but there just hasn't been time for me recently. Jeremy is working on his PhD, and Thomas has allowed his professional life to get the better of him ;-).
Yeah having to work for a living really makes your live miserable ;-). Seriously I will have more time to deal with these things starting now. I.e. I am open to input I just currently don't have any good ideas on how to improve the whole thing.
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 }; 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! -- Dave Abrahams Boost Consulting www.boost-consulting.com