Re: [boost] (infinite) sequences using recurrence relations

From: Corwin Joy (cjoy_at_[hidden])
Date: 2001-08-10 12:31:14

----- Original Message -----
From: "Douglas Gregor" <gregod_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, August 10, 2001 2:43 AM
Subject: Re: [boost] (infinite) sequences using recurrence relations

> On Friday 10 August 2001 02:21, you wrote:
> [snip]
> > My advice is, again, look at the standard as I suggested in my previous
> > post on this thread.  Look carefully as table 72 on p. 511 of the
standard.
> >  Note that a == b only implies *a "equivalent" to *b.  As I noted, my
> > interpretation based on istream_itreator and istreambuf_iterator is that
> > this equivalence means almost nothing as istreambuf_iterator may even be
> > pointing to different streams in the case of equality.  Also worth
noting,
> > is that the SGI trivial iterator requirement is also not satisfied,
> > a == b does not imply &*a == &*b as per istreambuf_iterator
> > or just look at the istream iterator code in the SGI library itself.
> > However, the more I think about it, the more I am convinced that this is
> > *NOT* a defect but actually a deliberate design decision.
>
> Perhaps the second condition to the statement in table 72 is the most
> important, because it is specifically: "If a==b and (a,b) is in the domain
of
> == then *a is equivalent to *b."
>
> For istream_iterator (ignoring implementations and looking only at the
> standard description):
>   - any two istream_iterators that reference the same istream are equal
based
> on operator==, so consider:
> istream_iterators i, j;
> j = i;
> ++i;
> i == j; // true, but invalid because (i, j) need not be in the domain of
==
>
> So, *i need not equal *j, and the equivalence condition from table 72
makes
> sense.
>
>   - Now let's ignore the intervening increment: since the "value" member
of i
> was initialized during the last increment, j = i will copy that value, so
> *i == *j must be true. Thus, the equivalence condition from table 72 still
> makes sense.

O.K. I agree, thank you for the very nice explanation of how this works for
input iterators
in general - that was very helpful to me.  Still, the way the standard
defines equality for
input iterator bugs me then since it seems to me that if (i, j) is not in
the domain of == the operator
should return false rather than returning true just because (i, j) point to
the same stream.

I also mostly agree with the reference counted implementation you give for
holding the data
in the input iterator.  I've done something quite similar to this in input
iterators I have coded
in the past.  One efficiency suggestion you might want to consider:

>   // same for postincrement
>   some_input_iterator& operator++()
>   {
       if (value.reference_count() > 1)
>     value.reset(new make_pair(T(), false)); return *this;
>   }
>