The C++ <random> Lame List

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

  1. Calling rand() or srand(). Lame.
  2. Using time(NULL) to seed an RNG. Inexcusably lame.
  3. Claiming, “But rand() is good enough for simple uses!” Dog lame.
  4. Using random_shuffle() to permute a container. Mired in a sweaty mass of lameness.
  5. Using default_random_engine. Nauseatingly lame.
  6. Using % to get a random value in a range. Lame. Lame. Lame. Lame. Lame.
  7. Not using random_device to seed an RNG. Violently lame.
  8. Assuming that random_device is going to do the right thing on your platform. Uncontrollably lame.
  9. Failing to handle a possible exception from the construction or use of random_device. Totally lame.
  10. Using anything in the standard but mt19937 or mt19937_64 as a generator. Intensely lame.
  11. Putting mt19937 on the stack. In all my years of observing lameness, I have seldom seen something this lame.
  12. Seeding mt19937 with only one 32-bit word rather than its full state_size. Pushing the lameness envelope.
  13. Forgetting that uniform_int_distribution works on a closed interval. Thrashing in a sea of lameness.
  14. Passing random_device or a generator to generate_n() by value, forgetting to wrap it with ref(). Glaringly lame.
  15. Failing to use seed_seq to initialize a generator’s state properly. Indescribably lame.
  16. Not considering thread safety when using a generator. Floundering in an endless desert of lameness.
  17. Using a global generator without making it thread_local. Suffocating in self lameness.
  18. Using RAND_MAX instead of 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…

Published
Categorized as C++

6 comments

  1. If you mean that having a 2504 byte stack frame is not a good idea, I agree.
    Raw performance is not affected, however.

  2. The blog post itself is lame. It doesn’t say absolutely anything why any of the use cases above are bad. Could be an interesting information for those new in the area.

    The Windows Sockets lame list offered some explanations at least.

    One more note: the link http://www.elbeno.com/blog/?p=1081 seems to be down, BTW

  3. Re Nicola: sure, but a generator on the stack implies it’s going to be re-initialized every time through the function.

    Re Adi: I saw that the WSLL had explanations added later on, but I decided to a) keep the list a list and not a TL;DR article, b) hopefully inspire people to research and understand the why themselves.

    There’s plenty already written about this elsewhere, I just thought this was a bit of fun.

    (And the link seems fine? Must have been some transient issue.)

  4. This list lacks the reason + alternatives that make the Winsock lame list fairly useful. Instead this article makes assumptions that the reader is already informed on the reasons why these things are lame and subsequently isn’t very helpful.

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.