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. 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. 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.
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 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. With respect to map_xxx iterators I always felt that something like this is sorely lacking. IN going ahaed I would much rather like to see an iterator_adaptor that iterates over a single/multiple index in a collection of tuples than a map iterator. Thomas -- Thomas Witt witt@acm.org