Re: [boost] Re: Determining interest in combining_iterator

From: Thomas Becker (tmbecker1_at_[hidden])
Date: 2003-03-28 06:18:00

<anthony.williamsNOSPAM_at_[hidden]> wrote:

> Thomas Becker <tmbecker1_at_[hidden]> writes:
> > Unless I'm missing something, I believe that my
> > original rough intuition was ok. Given my
> combining
> > iterator, it seems very easy to write your tuple
> > iterator by providing a simple generic
> > "reference-tuple-making" functional.

[...]

> The returned tuple of references is not copyable
> though --- the copies will
> still refer to the originals. I went through all
> this with my pair iterator;
> try using std::sort on your pair of vectors,
> especially with vectors of a
> non-POD UDT with no swap specialization, just to
> avoid any optimizations in
> your standard library. A plain tuple-of-references
> will screw up the vectors,
> you need something more complex.
> 
> Also, you can't use a tuple-of-references with input
> iterators, since they
> return values not references when dereferenced, so
> you need to know the
> iterator category and use a tuple of values in this
> case.
> 
> Finally, output iterators are even more bizarre, as
> writing to the result of
> dereferencing your combined output iterator needs to
> write to the result of
> dereferencing each of the individual output
> iterators, and there is no telling
> what type you get when you dereference an output
> iterator.
>  

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.

Thomas Becker
Zephyr Associates, Inc.
Zephyr Cove, NV
thomas_at_[hidden]

__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com