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; }
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. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com