Thanks for your comments on the combining iterator. > David Abrahams wrote: > It's a wonderful idea, Thomas! > > You might look at the Boost sandbox; Jeremy Siek, > Thomas Witt and I > are trying to finalize the work in the > boost/iterator and > libs/iterator directories to replace the current > iterator adaptors
Thanks for your kind words. I'll play with the sanbox stuff. Is the main purpose there to incorporate better iterator categories? Anyway, I won't take any further action until all that has settled down. > Douglas Paul Gregor wrote: > Sounds great. Since the functionality is a direct > generalization of > transform_iterator, I'd prefer to use the name > transform_iterator and > either (a) switch entirely to your > combining_iterator implementation or > (b) give transform_iterator_generator the brains to > switch between your > implementation and the existing implementation based > on the number of > iterators being adapted. Uh uh, I was kinda hoping nobody would bring that up, because I agree and at the same time strongly disagree. Of course you're right, the transforming iterator is a special case of the combining iterator, and under any kind of theoretical point of view, it should be treated as such. There is no way I can argue with you on that. And yet, I am very strongly in favor of keeping the two entirely separate. Here's why: From a library user's point of view, the fact that the transforming iterator is a special case of the combining iterator is quite accidental. If someone is looking for the functionality of the transforming iterator, she should find just that, without being forced to view the thing she's looking for as a special case of something completely different. One could in fact express this viewpoint in a somewhat theoretical manner by saying that the transforming iterator is not so much a *special* case of the combining iterator than a *degenerate* case. Combining iterators is not where one would naturally look when in need of a transforming iterator. > Anthony Williams wrote: > IMHO, it seems more logical to split the concept, so > the grouping of > the iterators is separated from the transformation By "separating the grouping and the transforming," do you mean to write an iterator that holds a tuple of iterators and then, upon dereferencing, returns the tuple of dereferenced values, and then use that in conjunction with boost's transforming iterator? That would make a lot of sense. However, I would need a little convincing that it really adds useful functionality that people are looking for. > Paul A. Bristow wrote: > I can see this VERY useful to some, but probably not > widely useful. In view of the emphasis on "very," I'll count that as a yes vote. Thomas Becker Zephyr Associates, Inc. Zephyr Cove, NV __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
