Avoid rand()
in the legacy tr1
test suite
#4921
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Our bosses and boss-like entities heard that
rand()
is considered harmful and are starting a push to avoid unnecessary use.Almost all of our mentions of
rand
are Standard-mandated (or Standard stable name citations), but I found a few unnecessary uses in our legacytr1
test suite. We avoid cleaning up its code unless there's a specific reason to mess with it, and this easily qualifies.tr1/tests/algorithm
rand_gen
anmt19937
data member. (Default construction is fine; we weren't attempting to seedrand()
before.) This is purely masking bits with& 0xfffff
, so there's no need for auniform_int_distribution
.frand()
wrapper with anrng_func
lambda. To avoid/clr:pure
problems with init-captures, I'm capturingmt
by reference (so the lambda doesn't need to bemutable
and doesn't need to be passed viaref()
). We need to adapt the half-open interface touniform_int_distribution
's fully-closed range.tr1/tests/memory2
mt19937 mt;
within thestatic void ctors()
worker function. (It's important to not use a global engine with multiple threads!) Again, we weren't attempting to seedrand()
, so default-constructingmt19937
is fine. And because we're just looking at a bit, we don't need auniform_int_distribution
.