Generating random numbers using C++ standard library: the problems

Portability of random number generation in C++ is also described in this blog post: <a href="http:&#x2F;&#x2F;anadoxin.org&#x2F;blog&#x2F;c-shooting-yourself-in-the-foot-4.html" rel="nofollow">http:&#x2F;&#x2F;anadoxin.org&#x2F;blog&#x2F;c-shooting-yourself-in-the-foot-4.h...</a>

The generator&#x2F;seeding design is gnarly, totally agreed.<p>I do want to disagree with the author on distributions. In most scenarios it is totally sufficient for distributions to be deterministic and reproducible on a given implementation&#x2F;architecture instead of ossifying them to one implementation mandated by the standard.

std::seed_seq and the SeedSeq concept look incredibly broken, also it looks way over-engineered. Why can&#x27;t a random generator engine just get a Calleable as a constructor argument and call it as many times as it needs to seed itself? SeedSeq tries to be way more than it needs to be while failing its basic requirement.

PCG is not the only game in town when it comes to high-quality reproducible and fast PRNGs: <a href="https:&#x2F;&#x2F;github.com&#x2F;lemire&#x2F;testingRNG#visual-summary" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;lemire&#x2F;testingRNG#visual-summary</a> Notably, some newer PRNGs are faster, and still pass all statistical tests.

Wouldn&#x27;t stability of output with given initial conditions totally freeze any ability to change the implementation in the future?

My anecdote with C++&#x27;s RNGS: I was getting different sequences of random values using std::minstd_rand on arm64 and arm32.<p>Turns out it was because the seed type is uint_fast32_t and I was passing a 64 bit seed. On arm32 the seed was getting truncated to 32 bits, but not on arm64. It was my fault but it was still surprising.

So you need a large stream of random numbers to seed your random number generator? Seems like a bizarre chicken and egg problem... If I <i>had</i> a source for large quantities of random numbers, why would I even need the second random number generator?

By default with gcc and clang on Linux, random_engine will use &#x2F;dev&#x2F;urandom.<p>I use &#x2F;dev&#x2F;random and configured it with rng-tools. With rng-tools you can configure the sources of entropy for rngd.<p>You can add a hw random number as entropy source there. Just do not add more entropy than the size of the entropy pool or your system performance will suffer.<p>Some people discard a number of generated values to make it harder to guess the internal state of the generator. discard_block_engine can be used for this too.<p>Anyways, if you want to test your random numbers try <a href="https:&#x2F;&#x2F;webhome.phy.duke.edu&#x2F;~rgb&#x2F;General&#x2F;dieharder.php" rel="nofollow">https:&#x2F;&#x2F;webhome.phy.duke.edu&#x2F;~rgb&#x2F;General&#x2F;dieharder.php</a>

One thing that isn&#x27;t mentioned in the article is performance.<p>C++ standard PRNG&#x27;s, on top of all the brokenness listed in the article are very inefficient, especially if you use distributions.

You can&#x27;t even count on std::random_device doing something sane. <a href="https:&#x2F;&#x2F;stackoverflow.com&#x2F;q&#x2F;18880654&#x2F;5987" rel="nofollow">https:&#x2F;&#x2F;stackoverflow.com&#x2F;q&#x2F;18880654&#x2F;5987</a>

I wrote a 64 bit random number generator in C. I didn&#x27;t think much of it, it&#x27;s only pseudo random.

&gt; every single part of it is deeply flawed, and the best solution is to avoid using it completely<p>You can sadly say the same for a large part of C++ standard features. At least the core language is mostly sound, simple intuitive and performant, so having to file off some edges is not that big of a problem.