[boost] Re: std::sort(zip_iterator...) does not compile

From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2004-07-23 07:50:19

David Abrahams <dave_at_[hidden]> writes:

> Anthony Williams <anthony_w.geo_at_[hidden]> writes:
>
>>> Which is why we have to change counting_iterator to not be a forward
>>> iterator.
>>
>> Darn. I missed that requirement --- I was working off table 74, which just
>> requires *a==*b if a==b (amusingly adding a requirement that the value type
>> supports operator== in the process). This requirement makes it actually
>> impossible to make an aggregating iterator anything other than an input or
>> output iterator.
>>
>> :(
>>
>> On the plus side, my tuple iterator works with std::sort on every compiler
>> I've tested it on. Do you know of any implementations that depend on this
>> requirement being met for any of the standard algorithms?
>
> I don't know, but it seems to me that there's another problem.  If
> one of the component sequences contains types whose copy ctor may
> throw, how do you write the internal cache back to the sequence
> without potentially throwing during destruction?  Consider passing
> the tuple iterator and a new value to this:
>
>         template <class Iterator, class Value>
>         void f(Iterator a, Value const& x)
>         {
>            *a = x;
>         }

The internal cache in the iterator does not hold any values, it is essentially
just an aggregator of references (derived from 
boost::typle<Iter1::value_type&,Iter2::value_type&....>). Since the sources
are separate there is no real object to reference for the return value of
operator*, so I had to make one.

Updates like in your example therefore directly update the objects in the
original containers, and so the problem you outline doesn't exist (thankfully).

However, this tuple object is special. When you copy it, then it actually
copies the referenced objects into a cache within the new copy. This avoids
accidental modification of the source data.

>> Maybe your effort on the new iterator categories can help with the problem?
>
> Maybe.  I hope so.  It's currently a political as well as a technical
> mess.

Yes, I've been following the discussions.

Anthony
-- 
Anthony Williams
Senior Software Engineer, Beran Instruments Ltd.