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

From: Douglas Gregor (gregod_at_[hidden])
Date: 2001-08-09 22:16:08

On Thursday 09 August 2001 06:01, you wrote:
> On Thu, 9 Aug 2001, Douglas Gregor wrote:
> > Personally, I would dereference to be stable (so that find()/find_if()
> > need to be changed to use forward iterators) but I would like == to be
> > defined only for:
> > i == i: always true
> > i == end: true if at end, false otherwise
> > i == j: always false
> >
> > This makes it reasonable to implement an input iterator that gets its
> > data from a volatile source: it can easily be cached on first access, but
> > you don't have to deal with sharing the cache among iterators.
>
> Sounds like a new concept volatile_iterator to me.
>
> John

I'm trying my hardest not to make it a new concept, because I think it is 
just a model of an input iterator. Understanding the exact input iterator 
behavior with respect to multiple dereferences and multiple copies of the 
iterator is essential in formulating such an iterator.

The example I'm dealing with: dereferencing an iterator calls a function 
(which may have side effects), and the return value is the result of 
dereferencing the iterator. If dereference and increment must alternate, then 
construction is trivial: operator* just calls the function. If dereference 
must be stable, the value must be cached. But if dereferencing is stable 
using different copies of equivalent iterators, the cached data must be 
shared by all versions. Consider this code:

input_iterator i = ..., j = ...;
if (i == j)
  assert(*i == *j); // ?

If this is true of input iterators, then istreambuf_iterator does not model 
an input iterator, because of 24.5.3.5p1: "Returns: true if and only if both 
iterators are at end-of-stream, or neither is at end-of-stream, regardless
of what streambuf object they use."

        Doug