Thomas Becker <[EMAIL PROTECTED]> writes: > > 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?
Yes, this is exactly what I meant. > 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. Personally, I have found several occasions where I have needed a pair of iterators to yield a pair of values, which is why I wrote my pair iterator. The particular example I cited in the article is where a colleague had a pair of vectors which were the x and y values respectively for a graph. They were supplied as two vectors, and the graph drawing code required them as two vectors, yet the analysis code in the middle required a sequence of (x,y) pairs --- initially for sorting by x value, but also to ensure that transforms were applied correctly and consistently. The alternative is to write functors to sort a list of indices and redirect through the index table whenever access to the data is required. I can imagine similar situations where a tuple of sequences must be treated as a sequence of tuples --- indeed, the supporting example for your combining iterator is precisely such a situation; the client code wishes to perform an operation on the tuple of values resulting from dereferencing the supplied tuple of iterators. I can build this from my pair iterator --- pairit(i1,pairit(i2,pairit(i3,...))) --- but it would seem to make sense to generalize the code to have a boost::tuple-friendly interface --- I think you would still need a custom tuple to handle the ownership issues (I may be wrong on this point, since I haven't studied boost::tuple in depth) 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
