Herb mentions the possibility of `is void` generalizing across pointers, std::optional, and std::future. This seems like it could create ambiguity with a future<void> wherein a non-ready future<void> `is void` and also a ready future<void> `is void`. How should it be handled, I wonder?
Thanks for the response. I think my disagreement is in describing that as "without synchronization", somewhere the caller is somehow ensuring there are no writes during their safe parallel reads.
This is the first time I've heard of "thread compatible" objects/state. The author states: "Most types in C++ are thread-compatible, as this guarantee comes mostly comes for free", and that "Any concurrent call to a non-const method must be synchronized by the caller."
My understanding is that due to things like memory tearing, or the possibility of invariants between object members being in intermediate states, reads are always unsafe when there is a possibility of writes. Therefore, you can't selectively skip having some kind of synchronisation for the const calls (the reads), as something needs to be synchronizing all the reads against any potential writes. So to me this just reads as, "the caller has to manage all the thread safety for all the accesses", which I'd agree is what typically "comes for free" in c++, but I'd hardly call it a "guarantee".
I'm wondering if I'm not seeing some meaningful level of "thread compatibility" in between "thread-safe" and the "accessor beware" behaviour of all c++ that wasn't designed to be thread-safe. Or is there an example of some c++ that is not even "thread-compatible" once the caller has accepted the burden of synchronization?
This subject is discussed in the pop sci work of PBS spacetime https://youtu.be/GcfLZSL7YGw with reference to articles and books if you're looking for more
I don't get that option, and instead get a message referencing HSTS, presumably because at some point in the past my browser picked up the HSTS setting for the site.
This might be banks trying to detect compromised users. Many "tech support" scams aim to get remote desktop access to users PC's and then have them log in to their bank while scammers are connected. I could see how banks looking for remote access software could be a useful heuristic in fighting this problem.
Not FPS specifically, but you might enjoy Riot Games' tech blog https://technology.riotgames.com/ which has articles on a variety of game technology things such as service deployment, network infrastructure, game performance monitoring etc.
https://urlshortenersaresoyesterdaytrythisamazingsuperlongur...
This reminded me of a backend-less filesharing site I once made
https://efokschaner.github.io/furl-unfurl/#/