From: Jens Maurer (jmaurer_at_[hidden])
Date: 2000-02-21 20:26:45
Beman Dawes wrote:
> >We've basically got the choice between three interfaces:
> > (1) The Generator STL requirements, i.e. operator() (only)
> > (2) operator++ / value()
> > (3) Iterator in the STL sense, i.e. operator++ and operator*
> In larger classes it is usually a serious mistake to try to provide
> two distinct (let alone three) interfaces.
I've implemented a generator_iterator decorator and extended
random_demo.cpp to show the usage. However, the iterator
interface isn't that useful anyway, because I haven't found
an STL algorithm you could sensibly use with this kind of
iterator: algorithms usually want some "past-the-end" iterator
to say "STOP" to them, which we simply cannot provide for random
numbers in the general case (that's why they're random, after all).
Does anyone have convincing arguments why (3) fits more nicely
in some existing framework such as STL?
Is using the generator_iterator decorator too much a nuisance for
the casual user? Personally, I'm still very happy with saying
int tmp = rng(); if(tmp < 1 || tmp > 5) do_this(); else do_that();
Using explicit function-call syntax (albeit on a function object)
shows to the user that potentially voluminous things are going on
behind the scenes. Consider random_device as an example. However,
I recognize "++rng" as some lightweight operation, such as
incrementing an integer or pointer or advancing an iterator,
which are all just a few clock cycles. In short, providing an
operator++ violates the principle of least surprise for me.
> Done. Except I spelled it BOOST_NO_INCLASS_MEMBER_INITIALIZATION.
I split the documentation. random-classes.html became
random-generators.html, random-distributions.html, and random-misc.html.
The latter is for the generator_iterator and random_number_generator
decorators. There's a new index.html to guide you through the chaos.
random.hpp got shuffle_output (thanks to Harry Erwin for sample code)
and inversive_congruential_schrage generators (see the documentation
for details) to broaden the choice of vastly different generators.
Then, there's a uniform_smallint distribution function with extensive
quantization effects coverage in the documentation (Valentin, are you
listening?) uniform_int is also there, but not yet polished.
All (for free!) at http://www.egroups.com/docvault/boost/random/
The next update will move random_device to a fresh directory and
out of random.hpp, unless anybody objects.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk