Re: [boost] Review: Iterator adaptors

From: David Abrahams (abrahams_at_[hidden])
Date: 2000-12-29 12:58:18

----- Original Message -----
From: "Jeremy Siek" <jsiek_at_[hidden]>

>
> In general, I like the suggestions to sprinkle "generator" into
> the names.
>
> On Thu, 28 Dec 2000, David Abrahams wrote:
> abraha> > * Issue to work out with Jens Maurer:  Conceptually
integer_range and
> abraha> > generator_iterator are similar.  Are they similar enough so that
the names
> abraha> > should be coordinated?  Or could one even subsume the other?
(Jens: it
> abraha> > would help if http://www.boost.org/libs/random/random-misc.html
had usage
> abraha> > examples.)
> abraha>
> abraha> Whoops, that may make iterator_generator a confusing name for me
to use. Is
> abraha> generator_iterator actually more similar to transform_iterator? We
need to
> abraha> work this out.
>
> Doesn't generator_iterator create random numbers?

Look at the documentation. Actually, it calls an arbitrary function object
repeatedly to generate any series.

> This has nothing in
> common with integer_range which creates a series of numbers increasing
> by 1.

I was claiming that it had something in common with transform_iterator,
which looks like a small generalization of generator_iterator to me.

I am worried about the idea of using iterator_generator as a name (though I
think this is the best choice) while we still also have a
boost::generator_iterator. Maybe we could dispose of generator_iterator in
favor of transform iterator, but maybe I shouldn't worry: generator_iterator
is also a good name ;-)

> abraha> > * The transform_iterator_policies() default constructor looks
odd.  Is it
> abraha> > correct?  It looks like a safety issue - a default constructed
> abraha> > transform_iterator_policies instance will be leave m_f invalid.
> abraha>
> abraha> I think that's OK. Since m_f is an AdaptableUnaryFunction, it
can't be a raw
> abraha> pointer-to-function. Did Jeremy already answer this?
>
> We're forced to have a default constructor because iterators have to
> have default constructors, and the policy class will be a data member of
> the iterator.

I think Beman was probably worried about the m_f field being uninitialized,
and that can only happen if it is a fundamental type. I'm saying that it
can't be a fundamental type, so /its/ default constructor will be invoked
automatically. Beman?