On Fri, 4 Mar 2011 09:36:03 -0800 "Dick Bridges" <Dick.Bridges@wdc.com> wrote:
As long as I'm asking, perhaps the ability to provide a special-purpose generator of our own design?
You already can. :-) The random.hpp classes are there only for convenience. In all of the few functions that use a random generator, you can substitute any Boost.Random generator class, or any other class that has a similar interface. If you've got specialized random-number- generating hardware, the code will happily work with it, with nothing extra but a simple interface class. </snip>
If I might make a suggestion, the XInt library interface could be simplified by removing all notions of RNG quality (strong, random, etc.) and become more in line with the goal of providing a POD-like data type.
Yes, but it would require pulling Boost.Random into the example code, which would complicate it.
On an abstract [carefully avoiding 'generic'] level, an RNG is an RNG is an RNG. One of the problems I see with syntactic candy like 'strong_random_generator' is that it implies the generated values are both cryptographically acceptable and actually random (and verified by the library). IIUC, there is nothing in the library that attempts to verify either.
The Windows implementation uses the formerly-undocumented RtlGenRandom function, which is what Microsoft's own cryptography library relies on for random numbers. The POSIX implementation uses /dev/urandom, which has well-known strengths and limitations. As an amateur cryptographer, I consider the silence of professional cryptographers on their strengths to be proof enough that they're sufficiently cryptographically strong for most uses. Especially considering the uproar from them a few years ago when a coding mistake made the Debian distribution's generator much weaker for a while.
IMHO, the XInt library should make no pretense wrt RNG quality - let the user specify the RNG or use the default (as is now provided by default_random_generator).
The user can, and in fact must. The default_random_generator was truly a default in earlier iterations of the library, but neither of those classes are used for anything except the example code now. -- Chad Nelson Oak Circle Software, Inc. * * *