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.