From: David Abrahams (dave_at_[hidden])
Date: 2004-07-23 07:17:03
Anthony Williams <anthony_w.geo_at_[hidden]> writes:
>> Which is why we have to change counting_iterator to not be a forward
> 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
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk