Not to focus on a question unrelated to this blog post's point, but<p>* "auto main() -> int" could be just "int main()".<p>* "auto v = vector<int>(20);" could be just "vector<int> v(20)".<p>* "auto print_value = [](auto&& v)" could be (I'd argue <i>should</i> be) "auto print_value = [](const auto& v)".<p>"auto" is useful, "auto" is great. But "auto" is not an end in and of itself.<p>(Bring on the C++(11) haters, blah blah.)
Interesting to see that OpenBSD recently went the other way: break the standard and make rand() a good random generator by default. Even to the point of making srand(time(0)) a no-op.<p><a href="https://news.ycombinator.com/item?id=8719593" rel="nofollow">https://news.ycombinator.com/item?id=8719593</a>
"The C random library has always been… to put it politely… less than ideal. Okay, it’s pretty fucking horrible. It’s so bad that the C standard itself suggests you’d be better off not using it."<p>Back in the days 4.2 BSD or so, the BUGS section of the manual entry for rand understatedly mansplained that it had "bad spectral characteristics". In fact, it was so bad that the lower bit alternated between 0 and 1 every time you called it. Hard to miss that bright line on a spectrogram.<p>If you couldn't figure out what to expect from such a forthright disclosure in the manual, then you were in for quite a shock when you did the obvious thing and tried to use "rand() & 1" to simulate flipping a coin!
Why is a specific random generator should be in the standard at all? Random generators are quite a dangerous area.<p>Picking one is not without compromises:
Do you want your PRNG fast? Or do you want it cryptographically secure?<p>It could become obsolete in less time than expected.
It's mostly true for CSPRNGs. Maybe that's why they are considering Mersenne Twister which is "good enough" for many use cases but not meant to be cryptographically secure. Sure, I'm using it right now for physics simulation and it's certainly good enough for that and it's hard to imagine a case where a 623-dimansionally equidistributed PRNG could fail. But it most certainly can if it can't be used for cryptography. It is <i>much</i> better than rand() though and one could argue that it will be good enough 99% of the time. The problem that you can't replace it if it ever becomes obsolete since some software depends on the predictability and still random like features of PRNGs (like game map generators, digital art, etc...).<p>I think the one boost library they should standardize is boost's random device. PRNGs could become obsolete but "truly random" will always mean the same. However it's not trivial that one has access to a truly random source and in that case it should fall back to fail. At least it could kill the practice of seeding with time.
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.<p>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.<p>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.<p>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.