ofrzeta6 hours ago
"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.
fc417fc8025 hours ago
And then immediately afterwards we see const T* in a supposedly immutable data structure meaning the pointer remains mutable. Yet another classic footgun.
mooreat4 hours ago
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.
eps7 hours ago
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.
xeyownt6 hours ago
Yes, it's more an infinite cylinder.
jdw649 hours ago
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.
nnevatie5 hours ago
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.
gpderetta4 hours ago
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.
nnevatie3 hours ago
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.
hiroakiaizawa7 hours ago
Interesting approach. I like that the implementation focuses on scalability rather than only visualization.
HarHarVeryFunnyan hour ago
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.
ontouchstart4 hours ago
This would be a cool template project to learn C++ without the pollution of LLM slop.
classified8 hours ago
Fricking cool, I love it.
