On 26 Mar 2003, Anthony Williams wrote: > It strikes me that if you dereference n iterators, you have n values, and the > most natural way to store them is a tuple. Doing anything other than returning > this tuple seems to me just complicating the usage.
I would agree if tuples and argument passing were more closely linked, i.e., if passing a tuple to a function meant that the tuple would be automagically unpacked into separate arguments. But that's not the case, so the introduction of tuples as the return type makes it harder to then apply a function object to the values. For instance, consider an iterator that adds the values from two other iterators (with the combining iterator): make_combining_iterator(first.begin(), second.begin(), std::plus<int>()); With the tuple iterator, you need to either (a) write your own std::plus-like function object that accepts a tuple<int, int> instead of two int parameters or (b) use something like Aleksey's apply (?) function that unpacks a tuple and applies the separate arguments to a function object. > How do you write the following with your combining iterator? (TupleIt is a > supposed generalisation of my PairIt which returns a tuple rather than a pair) [snip] > std::sort(makeTupleIterator(first.begin(),second.begin(),third.begin()), > makeTupleIterator(first.end(),second.end(),third.end()), > myCompareFunc); makeTupleIterator(first.begin(), second.begin(), third.begin()) is equivalent to make_combining_iterator(first.begin(), second.begin(), third.begin(), &boost::tuples::make_tuple<int, int, int>); [I'd still like to call it a (generalized) transform iterator] Doug _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost