Anthony Williams <anthony_w.geo@yahoo.com> writes:
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.
Oh, then it doesn't conform in another way. operator* on a ForwardIterator must return a real reference. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com