Boost logo

Boost :

From: Jeremy Siek (jsiek_at_[hidden])
Date: 2000-12-29 00:21:29


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? This has nothing in
common with integer_range which creates a series of numbers increasing
by 1.

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.

abraha> > It also
abraha> > seems a bit odd that transform_iterator_policies is a struct rather than a
abraha> > class - I must be missing something.
abraha>
abraha> Well, I think you're right at least that the data member should be private.
abraha> Comments, Jeremy?

Yes, should be private.

Cheers,
Jeremy

----------------------------------------------------------------------
 Jeremy Siek www: http://www.lsc.nd.edu/~jsiek/
 Ph.D. Candidate email: jsiek_at_[hidden]
 Univ. of Notre Dame work phone: (219) 631-3906
----------------------------------------------------------------------


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk