Rendered at 13:28:04 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
ofrzeta 2 days 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.
fc417fc802 2 days ago [-]
And then immediately afterwards we see const T* in a supposedly immutable data structure meaning the pointer remains mutable. Yet another classic footgun.
mooreat 2 days 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.
fc417fc802 2 days ago [-]
I just double checked and don't see any const pointers, only mutable pointers to const data.
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.
nnevatie 2 days 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.
gpderetta 2 days 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.
nnevatie 2 days 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.
hiroakiaizawa 2 days ago [-]
Interesting approach.
I like that the implementation focuses on scalability rather than only visualization.
HarHarVeryFunny 2 days 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.
classified 2 days ago [-]
Fricking cool, I love it.
ontouchstart 2 days ago [-]
This would be a cool template project to learn C++ without the pollution of LLM slop.
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.
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.