59 points by HeliumHydride 2 days ago | 13 comments
- "I had heard the rumors that C++ was a scary language filled with footguns and segmentation faults, but I had never given it a fair chance myself" - props for this. There's too much hearsay in software engineering.
- And then immediately afterwards we see const T* in a supposedly immutable data structure meaning the pointer remains mutable. Yet another classic footgun.
- It looked to me like most of the raw pointers in the blog were const. Sometimes you don't want the baggage of smart pointers and getting a cheap easily copyable view of your data is nice, so you want to return a const T. Usually if an API returns a const T I assume lifetimes are handled for me and that the ptr is valid as long as it is not nullptr.
- Small nit, this - https://ryanjk5.github.io/assets/2026-05-14-GOLDE/torus.gif - is not what's conventionally referred to as a torus in CGoL. In torus left and right edges are also connected.
- Yes, it's more an infinite cylinder.
- It seems like the thread_local CacheIndex only determines which cache to use, but it doesn't actually guarantee thread safety for concurrent access to the HashLifeCache itself. What would be a good solution for this?
Should I use a mutex for each cache instance? As a beginner developer, my guess is that the original author assumes data races won't occur based on the execution timing. However, I'm really not sure if that assumption is actually correct/safe.
- In my view, thread_local is a bit of a code/design red flag. I didn't read the entire code in this case to see whether the thread_local use is warranted or not, though.
- a thread_local is just a global variable. Mutable global variables are of course bad, but in this case the threadindex is immutable once created, so it is perfectly fine.
- Yes, technically it is of course fine, just as a design I find use of thread_local is more of an afterthought than something I'd prefer.
- Interesting approach. I like that the implementation focuses on scalability rather than only visualization.
- It's extremely inefficient, using pointers to neighboring cells.
If you want to handle the grid edges (whether for a wrap-around "infinite" grid, or not) without too much special code, then leave a 1-cell border around the grid and fill this with the appropriate data (empty cells, or wraparound cells). If you really want to be efficient then just write the special-case edge code.
- This would be a cool template project to learn C++ without the pollution of LLM slop.
- Fricking cool, I love it.
