From: Anthony Williams (anthony.williamsNOSPAM_at_[hidden])
Date: 2003-03-28 10:48:49
Anthony Williams <anthony.williamsNOSPAM_at_[hidden]> writes:
> Thomas Becker <tmbecker1_at_[hidden]> writes:
> > I see now that with your tuple iterator, you are
> > aiming much higher than I previously thought. Just
> > like boost's transform iterators, my combining
> > iterators are always and necessarily input iterators.
> > (That's not really going to change under the new
> > proposed iterator categories, although they'll help
> > me.) I can cheat a little by returning a value that
> > happens to hold a bunch of references, such as a
> > boost::tuple of references. Nothing prevents me from
> > doing that. But you want a parallel-iterator that one
> > can, for example, pass to std::sort and have it order
> > the underlying sequences lexicographically. That's a
> > tall order. My combining iterator does not cover that.
> > Neither do I think that my combining iterator is
> > affected much by the ultimate solution to your
> > problem. My combining iterator is a multi-dimensional
> > boost::transforming_iterator. Yours would end up being
> > a multi-dimensional boost::projection_iterator. That's
> > a different colored horse.
>
> Yes, it's different, but it still has the same underlying parallel-iteration
> problems to solve, so there might be some common ground. Which is what I've
> been trying to say all along, though I didn't really state that in plain
> text. It might be that the common ground is at a lower level than the iterator
> dereferencing which has been focussing our attention, and it might be that
> there is sufficiently little to make it not worth sharing, but I thought it
> worth exploring.
FWIW, I've extended my pair iterator to be a tuple iterator for
input/forward/bidirectional/random-access iterator categories, which was
relatively painless. I will boostify it, add output iterator support back in,
and test it with VC7.1 as well as g++ 3.2.2, if you (or anyone else) are
interested.
Anthony
-- Anthony Williams Senior Software Engineer, Beran Instruments Ltd. Remove NOSPAM when replying, for timely response.