Re: [boost] Input caching iterator adaptor

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-06-30 18:01:24

I understand the problem now. I think this warrants a new LWG issue:

"is the result of dereferencing an input iterator stable?"

I guess that this might imply a new axis for Jeremy's proposed iterator
categories.

-Dave

----- Original Message -----
From: "Douglas Gregor" <gregod_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Saturday, June 30, 2001 5:48 PM
Subject: Re: [boost] Input caching iterator adaptor

> On Saturday 30 June 2001 05:38, you wrote:
> > ----- Original Message -----
> > From: "Douglas Gregor" <gregod_at_[hidden]>
> >
> > > It comes down to this, I think: If I have an input iterator i, must I
get
> >
> > the
> >
> > > same result if I evaluate *i twice without an intervening increment?
> >
> > Yes. Table 72 sez:
> >
> > "If a==b and (a,b) is in the domain of == then *a is equivalent to *b."
>
> Depends on the meaning of "equivalent". If a ==b, I can replace a *a with
a
> *b or vice-versa, but does it mean that I can evaluate both (sequentially)
> and have the results be equal?
>
> [snip]
> >
> > > The most convincing argument I've heard that consecutive dereferences
are
> >
> > all
> >
> > > equivalent is to consider std::find_if. It returns an input iterator
> >
> > (which
> >
> > > it would have dereferenced already to call the predicate).
std::find_if
> >
> > would
> >
> > > be useless if you couldn't rely on getting the same value back when
you
> > > dereferenced the result.
> >
> > So what has this got to do with your proposal?
>
> It's an alternative argument othe one you presented (a==b implies *a is
> equivalent to *b), because I'm not sure your argument is valid (see
above).
>
> > > Sad but true. Note that STLport and GCC's libstdc++ v3 (both variants
of
> > > SGI's STL) require their value types to be default constructible.
> >
> > Huh? Which value types are you referring to? Not the value_types of
> > standard containers! At least I know this about STLPort.
>
> The phrase missing from my sentence was "istream_iterators" :). The
> istream_iterator implementations for both libraries require that their
> value_types be default constructible.
>
> > > This adapter may in fact be useful, but I think you need to think
about
> >
> > the
> >
> > > > rationale and application a bit more carefully. The one you gave
> > > > doesn't seem to work.
> >
> > I don't think I've changed my mind yet...
> >
> > -Dave
>
> Nor have I been able to properly explain myself yet :(.
>
> Returing to the transform iterator, consider a function object like this
used
> in a transform iterator:
>
> struct plus_random {
>   typedef int argument_type;
>   typedef int result_type;
>
>   int operator()(int x) const { return x + std::random(); }
> };
>
> Now given transform iterator adaptors a and b with plus_random as the
> transforming function, a == b implies that *a and *b are interchangeable,
but
> the C++ expression *a == *b is not necessarily always true.
>
> Doug
>
> Info: http://www.boost.org  Unsubscribe:
<mailto:boost-unsubscribe_at_[hidden]>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>