Boost logo

Boost :

Subject: Re: [boost] Boost.Uuid and header-only support
From: James E. King, III (jking_at_[hidden])
Date: 2017-11-06 13:26:02


On Mon, Nov 6, 2017 at 7:49 AM, Peter Dimov via Boost <boost_at_[hidden]
> wrote:

> Paul A. Bristow wrote:
>> > I have been following this erudite discussion with interest, but >
>> ignorance.
>> >
>> > Without wishing to add even more entropy, may I suggest that adding
>> more > options is rarely a bad thing, but it creates an even more
>> bewildering > set of options for the user (for UUID, I fear as ignorant as
>> I).
>>
>> That is why I'd like the default generator to do the right thing and
>> doing the wrong thing to be harder and not be presented as an equivalent...
>>
>
> ... or more "optimal"...
>
>
> alternative.
>>
>
I'm planning to change random_generator to use the header-only
random_device
based on points made in this discussion:

1. It is more secure.
2. I believe it is the most widely used use case: generating a uuid
relatively infrequently
(i.e. not in bulk).

Therefore it will look something like this:

//
// The default random_generator uses operating-system provided entropy,
// is the most secure, and fastest random uuid generator for creating a
// small number of uuids with a single generator because it does not need
// expensive seeding to be effective like a PseudoRandomNumberGenerator
// does.
//
typedef basic_random_generator<detail::random::random_device>
random_generator;

//
// The bulk generator uses a mersenne twister to make random uuid
generation of
// many uuids from a single generator more efficient, at the expense of
security
// and guaranteed randomness.
//
typedef basic_random_generator<mt19937> random_generator_bulk;

This is a breaking change for anyone providing their own mersenne twister
to the
random_generator constructors that take a UniformRandomNumberGenerator.
I expect this would be quite rare, and in that case one could switch to
using _bulk
easily enough.

Please correct me if I misinterpreted anything.

I'll have a PR into my fork for a dry-run through CI later today and I'll
post the link here.

- Jim


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk