"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.
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.
Interesting approach.
I like that the implementation focuses on scalability rather than only visualization.
This would be a cool template project to learn C++ without the pollution of LLM slop.
"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.
Interesting approach. I like that the implementation focuses on scalability rather than only visualization.
This would be a cool template project to learn C++ without the pollution of LLM slop.
Fricking cool, I love it.