From: Anthony Williams (anthony.williamsNOSPAM_at_[hidden])
Date: 2003-03-28 06:44:38
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
-- 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