Re: [boost] Boost.Uuid and header-only support

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 
internally.

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 
Windows.

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.