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.
> 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 Williams Senior Software Engineer, Beran Instruments Ltd. Remove NOSPAM when replying, for timely response.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk