I don't agree with several of the points raised in that post.
|rand() has a very limited range.|
Totally irrelevant when you can call rand() three times and assemble a uint32_t that way.
|Nothing about rand()‘s behaviour is required.|
Interesting way of arguing. Mention first what it actually does (have a small range) and then what it might do. Somewhere. Maybe. Please don't ask for examples.
|You’re probably seeding it wrong.|
Actually, you're probably not
seeding it wrong. If someone is using rand() because they don't know any better, how likely is it that their code will start more often than once per second?
|You’re probably converting it to a range wrong.|
Bias is such a dumb argument. If we take the very common MAX_RAND == 32767 and you try to modulo the output of rand() to the range, say, [0; 42), the probabilities of the values in the range [0; 7) will be approximately 1/780 higher than those of those in the range [7; 42). Granted, the bias does get worse the larger the divisor, with % (MAX_RAND - 1) being the worst possible case, causing 0 to be twice as likely as any one of the other values. In absolute terms, though, the probability of 0 turns out to be 0.0061% instead of 0.003%.
|I know I have run across that attitude here when I have suggested someone look at how C++ can be used to generate pseudo-random numbers, instead of relying on srand/rand.|
<random> is garbage. I'll roll my own xorshift and seed it with std::random_device sooner than I'll use those std::mt19937 and std::uniform_distribution abominations.
It's like <iomanip> all over again. Let's take something that's intuitive and easy to use, if a little broken, and "improve" it until it's so cumbersome that people start rolling their own implementations just to avoid using it.
Whether these issues with rand() are actually problems or not again depends on what you're using rand() for. If you're doing Monte Carlo or cryptography and you're using rand() then sure, I'll agree that there's something wrong with you. For other situations, it's much less clear.
If you want an example where having a weak PRNG can be good, Google "rng hacking". Long story short, old consoles weren't very good at generating random numbers because they couldn't seed generators with unique values, so games that needed randomness used other tricks to get entropy, such how long it took you to push start on the title screen. In the particular case of Pokemon Red, the game continually gets entropy from all the buttons. A normal player will just go about their business and not even realize what's going on, but a clever player can abuse the PRNG to get better numbers for themselves. It adds an entirely new layer of complexity to the gameplay.