[boost] Re: Library proposal --- pair (and tuple) iterators

From: David Abrahams (dave_at_[hidden])
Date: 2003-09-23 06:09:26

Anthony Williams <anthony.williamsNOSPAM_at_[hidden]> writes:

> Thomas Becker <tmbecker1_at_[hidden]> writes:
>> --- Anthony Williams
>>> *it MUST be a real reference to the value type for
>>> Forward/bidi/random access
>>> Iterators (see table 74 of the standard).
>>> 
>>
>> The zip iterator that's in the Boost CVS right now was
>> written under the assumption that the new iterator
>> categories are available. These new categories were
>> designed primarily to solve the exact (annoying) issue
>> with the old categories that you mention: in order to
>> have certain traversal properties, such as random
>> access, one had to have certain access properties,
>> such as *it being a reference. Under the new
>> categories, that problem has gone away. Therefore,
>> what you have should be very useful in a context where
>> only the old categories are available, but is probably
>> unneccessarily heavy when the new categories are
>> present.
>
> Possibly, but the new categories aren't here yet, are they? They're not even
> in the library TR, so code written today still needs to deal with the reality
> of the current iterator categoriess. As it stands, the zip iterator can't even
> claim to be a forward iterator if it doesn't return a reference from *it,
> which makes it useless with a very large category of algorithms, even though it
> might otherwise meet all the requirements of a random access
> iterator.

Not really useless.  Very few algorithms depend on actually addressing
lvalues.  For most algorithm implementations, either the algorithm
dispatches based on category and has an implementation which works on
input iterators, or it "requires" a random access iterator and it
doesn't bother to check the category.  It's only the algorithms which
actually depend on addressing lvalues or which will do a static
assertion of the category which will break.
>
> If you think that this is an acceptable scenario, then that's your
> choice, and I'll pursue my submission as an alternative that works
> with current algorithms, but is more heavyweight. Otherwise, I'm
> happy to help enhance zip iterator to work with the current
> categories, if you wish.

I think it makes sense to have an additional template parameter to
zip_iterator which causes it to be an lvalue iterator.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com