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
> abraha> > generator_iterator are similar. Are they similar enough so that
> abraha> > should be coordinated? Or could one even subsume the other?
> abraha> > would help if http://www.boost.org/libs/random/random-misc.html
> abraha> > examples.)
> 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
> 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> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk