[boost] Re: Determining interest in combining_iterator

From: Anthony Williams (anthony.williamsNOSPAM_at_[hidden])
Date: 2003-03-25 05:30:10

Thomas Becker <tmbecker1_at_[hidden]> 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.