|
|
|
|
|
|
by arsv
4143 days ago
|
|
|
The title is grossly misleading. It should read "C++17 people choose Boost over std::rand() for their RNG needs" or something like that, a hardly surprising statement since C++17 people would choose Boost for pretty much anything else as well. In particular, it has little to do with rand() (as in rand(3) from libc), which has its uses as well as well-known alternatives within C world. As a side note, it's funny to see fresh new C++ code that boils down to srand(readintfrom("/dev/random")), except /dev/random is now given an "abstract standard name" random_device. And that part about limited seeding options. Beats me Boost (the library) alone won't fit in the memory of a device with 16bit ints, so inability to seed the RNG will be among the least of their problems. |
|
|
One of the largest user audiences of C++ is game developers, and (excluding mobile) 99% of their target platforms don't have /dev/random, so it's perfectly normal to want an abstract random device.
As a side note, if you've actually read the article through you'd learn that:
1. The Boost.Random stuff entered the C++ standard back in TR1 (published in 2007), way earlier than C++17. 2. Even if your seed is perfectly random, rand() would give you crappy distribution. 3. srand()/rand() is not re-entrant, which makes it a really bad idea to use it in any codebase that has a chance to grow larger one day. 4. Even if the seed is truly random, rand would give you crappy distribution and thus it has no legitimate uses other than making a game where its easy to cheat. 5. None of the rand() alternatives is in the C standard, and most are highly platform-specific. C++, on the other hand, had very good standard random generators for the last 8 years or so, which is very nice for the language that didn't even have standard strings for 15 of its existence.