Boost logo

Boost :

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


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