rand() Considered Harmful
aghuttun1 HN recommender · recommended in 1 month, 2019–2025
talk · intermediate · evergreen · 2019–2025 on HN
Stephan T. Lavavej's GoingNative 2013 talk explaining why calling rand() and using rand() % 100 is bad in C++, and how the C++11 <random> header does the job properly.
It is the standard reference for why rand() is broken in C++ and what to use instead.
Up next
6 mo on HNRobust-first computing: Demon Horde Sort (full version)
Dave Ackley
3 HN recommender · 2015–2023
11 mo on HNCppCon 2015: Andrei Alexandrescu “std::allocator...”
CppCon
7 HN recommender · 2017–2025
12 mo on HNLexical Scanning in Go - Rob Pike
GoogleFOSSSydney
13 HN recommender · 2012–2025
10 mo on HNCppCon 2017: Matt Kulukundis “Designing a Fast, Efficient, Cache-friendly Hash Table, Step by Step”
CppCon
9 HN recommender · 2018–2026
9 mo on HNRustConf 2018 - Closing Keynote - Using Rust For Game Development by Catherine West
Rust Programming Language
9 HN recommender · 2018–2023
10 mo on HNCppCon 2016: Jason Turner “Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17”
CppCon
13 HN recommender · 2016–2024
9 mo on HNIdeas about a new programming language for games.
Jonathan Blow
7 HN recommender · 2014–2025
9 mo on HNCppCon 2014: Mike Acton "Data-Oriented Design and C++"
CppCon
9 HN recommender · 2015–2026
9 mo on HNHow I program C
Eskil Steenberg
8 HN recommender · 2017–2025
9 mo on HNGoogle I/O 2012 - Go Concurrency Patterns
Google for Developers
9 HN recommender · 2012–2025
7 mo on HNCppCon 2015: Kate Gregory “Stop Teaching C"
CppCon
7 HN recommender · 2016–2025
7 mo on HNZig: A programming language designed for robustness, optimality, and clarity – Andrew Kelley
Recurse Center
6 HN recommender · 2018–2024
3 comments from Hacker News
Whenever I see such libraries, the first thing I check out is their PRNG implementation, and this one must be the worst I've seen so far. (The rest of the library is probably quite good, I'm just talking about the PRNG part) The library has one PRNG, and it is the following: tb_spinlock_enter(&g_lock); g_value = (g_value * 10807 + 1) & 0xffffffff; tb_spinlock_leave(&g_lock); Using this is literally worse than using the rand reference implementation. Also, tb_random_range uses a biased and slow implementation with modulo. (see link for the proper way to do this) I might look into adding a proper PRNG implementation, but I'll recommend a few resources: A lesson of what not to do: ▶ this video ("rand() Considered Harmful") Some good modern PRNGs: link , link , link Generating random numbers in a specific range: link
I used it because it was recommended by Stephan T. Lavavej, maintainer of Visual Studio's C++ Standard Library, in his "rand() Considered Harmful" talk, back when <random> was introduced. See 11m30s. ▶ this video
> Here is a short snippet of some abstract C++ code. As you can see, that is a code from the Windows DLL I stopped reading at this point. But, ok, I didn't really. I also noticed the code was quite dated / inopportune: * Has a "X-er" class - which probably shouldn't exist in the first place. * Using raw `delete` and `new` * Using unions instead of std::variant's * Using C library calls instead of `<algorithm>` functions (memset vs std::fill) * Using `rand()` instead of the standard library's facilities (even though it's broken ▶ this video ) So... it's outdated and inelegant C++, regardless of any actual errors.