Boost logo

Boost :

Subject: Re: [boost] Boost.Uuid and header-only support
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2017-11-04 11:39:12

On 11/04/17 02:58, James E. King, III via Boost wrote:
> Hi folks,
> I have an open defect related to a random seed generator that's currently
> in boost::uuids::detail called seed_rng. The class does a fair bit more
> than it really needs to, and does not support Universal Windows Platform
> (UWP) store targets. It is otherwise quite similar to
> boost::random::random_device however it is a header-only implementation (in
> fact seed_rng has a comment about putting it into Boost.Random). I was
> planning on removing it and leaving randomness to Boost.Random because
> that's where the code really belongs, however this would introduce a new
> library dependency on Boost.Random for any code using
> boost::uuids::random_generator. So I'm curious on how important folks
> believe it is to maintain the header-only status of Boost.Uuid.

I've expressed my opinion to you privately and will reproduce it here
just for the record.

I think the header-only property of Boost.UUID is an important feature
that enables some users to use the library. Whether that is due to a
project/company policy, pure convenience or other reasons is irrelevant;
the important part is that some users simply won't use separately
compiled libraries. Transiting to non-header-only state puts those users
in an awkward position, having to either port away from Boost.UUID
(likely, to a home-grown solution) or to adjust their policies and build
environment. Neither of those are good and easy outcomes.

Depending on how exactly you want to implement this, adding linking
dependency on Boost.Random can break POSIX users as autolinking is not
available on POSIX. (I.e. POSIX can be saved if you keep the current
header-only code for POSIX and only limit your change to Windows.)
Although autolinking can somewhat hide the problem on Windows, I don't
consider it a solution because it won't help if the compiled libraries
are simply not built.

With the Boost.Random proposal rejected, I can see the following
possible solutions:

1. Add the bcrypt-based implementation to the existing ones in
seed_rng.hpp. I think, this is the simplest to implement and it will
keep the users happy. Personally, I would do this.

2. Add your header-only random_device implementation proposed for
Boost.Random as an implementation detail to Boost.UUID and use it

3. Use std::random on newer compilers on Windows. Arguably,
std::random_device is supported on UWP as well as other Windows flavors.
Keep the current code for all other platforms and older compilers on

4. Use std::random universally on C++11 and later and Boost.Random on
C++03. This will break C++03 users but will maintain the header-only
property for C++11 and on.

Personally, I don't see the point in forcing the use of std::random or
Boost.Random. It looks nice from the maintainer's point of view (i.e.
separate concerns and let the random library deal with RNG), but given
that most of the code is already written in Boost.UUID and forcing
Boost.Random is actively harmful to Boost.UUID it is not worth it.

Boost list run by bdawes at, gregod at, cpdaniel at, john at