Network programmers of a certain age may remember the Windows Sockets Lame List.
I previously wrote a short “don’t-do-that-do-this” guide for modern C++ randomness, and I was recently reading another Reddit exchange featuring STL, author of many parts of Microsoft’s STL implementation, when it struck me that use of C++
<random> needs its own lame list to discourage using the old and busted C parts and encourage the using the new C++ hotness. So here, in no particular order, and with apologies to Keith Moore (wherever he may be) is an incomplete lame list for use of
time(NULL)to seed an RNG. Inexcusably lame.
- Claiming, “But
rand()is good enough for simple uses!” Dog lame.
random_shuffle()to permute a container. Mired in a sweaty mass of lameness.
default_random_engine. Nauseatingly lame.
%to get a random value in a range. Lame. Lame. Lame. Lame. Lame.
- Not using
random_deviceto seed an RNG. Violently lame.
- Assuming that
random_deviceis going to do the right thing on your platform. Uncontrollably lame.
- Failing to handle a possible exception from the construction or use of
random_device. Totally lame.
- Using anything in the standard but
mt19937_64as a generator. Intensely lame.
mt19937on the stack. In all my years of observing lameness, I have seldom seen something this lame.
mt19937with only one 32-bit word rather than its full
state_size. Pushing the lameness envelope.
- Forgetting that
uniform_int_distributionworks on a closed interval. Thrashing in a sea of lameness.
random_deviceor a generator to
generate_n()by value, forgetting to wrap it with
ref(). Glaringly lame.
- Failing to use
seed_seqto initialize a generator’s state properly. Indescribably lame.
- Not considering thread safety when using a generator. Floundering in an endless desert of lameness.
- Using a global generator without making it
thread_local. Suffocating in self lameness.
mt19937::max(). Perilously teetering on the edge of a vast chasm of lameness.
This list will undoubtedly grow as I continue to write lame code…