David Abrahams <dave@boost-consulting.com> writes:
Anthony Williams <anthony_w.geo@yahoo.com> 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.