Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2004-07-24 10:06:31

Anthony Williams <anthony_w.geo_at_[hidden]> writes:

> 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.

Oh, then it doesn't conform in another way. operator* on a
ForwardIterator must return a real reference.

Dave Abrahams
Boost Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at