Shore up the `grand' protocol.
This is a bit of a mess, really. There are two main problems.
* Firstly, the business of comparing function pointers simply doesn't
work on Windows, because the dynamic linker is too hopeless. If the
class implementation is in a different module from Catacomb itself,
then the vtable may have a pointer to an import-library stub, which
won't compare equal to the library's idea of the default method
function.
It's basically a mistake to have tried to use the same functions as
both user interface and default implementation. Split the two
apart. Leave the hacky function-pointer comparisons in the user-
interface functions for compatibility with existing out-of-tree
generators, which will carry on working about as well as they ever
did.
Note, however, that the defaulting strategy is now less `clever',
and implementations which don't provide native versions of all the
methods may end up suffering more than they used to.
* The `grand_range' function was simply broken if the `raw' method's
output is too small. Synthesizing a full uniform-value-in-range
from a narrow primitive generator in single precision arithmetic is
rather difficult, so rather than do that I've decided to insist that
all `raw' methods have a range of at least a byte's worth, so we can
synthesize a word generator out of bytes if necessary, and then use
that to satisfy the original larger range request.
This is all a bit unsatisfactory, really. I must remember to revisit it
when all of these gets made out of a proper object system.
15 files changed: