From: David Abrahams (dave_at_[hidden])
Date: 2002-11-01 02:40:18
Daryle Walker <dwalker07_at_[hidden]> writes:
> Right now, a generator is an object that returns a value from a
> zero-operand operator(). I wonder if we can make a similar concept
> that adds a Boolean conversion to a generator object. The conversion
> yields TRUE if the object can still return valid items, FALSE
> otherwise. This is for generators that have a limited usefulness that
> can't be determined in advance. The standard could have had these
> kind of generators for reading from input streams instead of having a
> clunky iterator adaptor with strange end-iterator properties. (You
> can still have clunky iterator adaptors, they would define a
> default-constructed iterator with an internal generator that is
> I'm posting this here because I'm thinking of generator ideas (like
> I/O) that should have this validity check.
I've been thinking in this domain recently also. However, I came to
somewhat different conclusions.
This came out of discussing the Random Number Library design with Jens
Maurer in Santa Cruz. He had an interface for seeding generators which
took an iterator range, and which would throw an exception if the
range was exhausted before the generator was fully-seeded. The size of
the range required for any generator was unspecified.
My feeling was that indeterminate "pull" interfaces like this one
should always use generators instead of iterators, and if the user had
only a limited amount of data to supply he should throw an exception
himself when it was exhausted.
However, your idea of supplying truth-value-testing also rings true
for me. The only real drawback is that you can't pass ordinary
function pointers, since they always test true. Hmm, maybe that's not
a drawback - they have no way to report failure other than throwing in
Maybe a good interface would check whether the generator was
convertible to bool and dispatch to a different implementation...
-- David Abrahams dave_at_[hidden] * http://www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk