On Sun, Nov 5, 2017 at 8:37 AM, Peter Dimov via Boost wrote: Andrey Semashev wrote: On 11/05/17 16:00, Peter Dimov via Boost wrote: James E. King, III wrote: In other words, the existing implementation may be optimal using a >>
PRNG. This depends on your definition of optimality. If speed is more >
important than not having UUID collisions, sure, it's optimal. Mersenne twister has a very long period - probably longer than any given
application can reasonably run to generate UUIDs, let alone a single
random_generator instance. In general when random numbers are concerned, the best default option is
to use crypto-secure numbers if you can afford it, because doing otherwise
may have security implications. You could have an active attacker guessing
the output of the PRNG given sufficient amount of output - which he'll have
if you generate 50M UUIDs per second. To eliminate even the slightest possibility of UUID collisions, you can re-seed the Mersenne twister PRNG periodically. This will reduce or eliminate its performance advantage. And performance of generating UUIDs can be significant in some circumstances. UUIDs are typically used as various resource identifiers
(think sessions, users, etc.), so poor performance can limit the rate of
allocation of such resources. Sure. As I said, if speed is more important than quality, it's optimal to
use a seeded-once Mersenne twister, and the option to do so will not be
going away. When it isn't, it isn't. (I've trouble imagining a scenario in which you won't run out of resources
if you allocate 50M resource identifiers per second, but let's suppose one
exists, for the sake of argument.) I'm adding boost::uuids::random_device_solo which is a
basic_random_generator of random_device (header-only) type,
and documented it as optimal for one-off UUID generation, whereas the
standard random_generator is best suited
to be reused (in a thread-safe manner) for multiple uuid generation.
boost::uuids::uuid u = boost::uuids::random_generator_solo()(); // avoids
PRNG setup overhead
I'm also adding unit tests to properly test all the Wincrypt and Bcrypt
failure paths in the header-only random_device.
It won't show up in the codecov reports from the linux build however.
It would be nice to have a more automated integration for leveraging
generation of gmocks inside Boost.WinAPI somehow...
(I'm not using gmock for this effort, just a suggestion) it would make
mocking the Win32 APIs easier.
- Jim