Thomas Becker <[EMAIL PROTECTED]> writes: > I see now that with your tuple iterator, you are > aiming much higher than I previously thought. Just > like boost's transform iterators, my combining > iterators are always and necessarily input iterators. > (That's not really going to change under the new > proposed iterator categories, although they'll help > me.) I can cheat a little by returning a value that > happens to hold a bunch of references, such as a > boost::tuple of references. Nothing prevents me from > doing that. But you want a parallel-iterator that one > can, for example, pass to std::sort and have it order > the underlying sequences lexicographically. That's a > tall order. My combining iterator does not cover that. > Neither do I think that my combining iterator is > affected much by the ultimate solution to your > problem. My combining iterator is a multi-dimensional > boost::transforming_iterator. Yours would end up being > a multi-dimensional boost::projection_iterator. That's > a different colored horse.
Yes, it's different, but it still has the same underlying parallel-iteration problems to solve, so there might be some common ground. Which is what I've been trying to say all along, though I didn't really state that in plain text. It might be that the common ground is at a lower level than the iterator dereferencing which has been focussing our attention, and it might be that there is sufficiently little to make it not worth sharing, but I thought it worth exploring. Anthony -- Anthony Williams Senior Software Engineer, Beran Instruments Ltd. Remove NOSPAM when replying, for timely response. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
