Boost logo

Boost :

From: Douglas Paul Gregor (gregod_at_[hidden])
Date: 2003-03-26 09:15:30

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

  make_combining_iterator(first.begin(), second.begin(),

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

> 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)
> 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]


Boost list run by bdawes at, gregod at, cpdaniel at, john at