Why intentionally design a worse alternative to std::weak_ptr which has been around since C++11??
One reason why this design can still be beneficial when using the standard std::shared_ptr in its implementation, is when you do not want to manage the pointee object by a std::shared_ptr (which is a requirement if you want to use std::weak_ptr). E.g., if you want to ensure that multiple objects of that type are laid out next to each other in memory, instead of scattered around the heap.
Another goal of the post is to show this idea, namely to use a shared_ptr<T*> (instead of shared_ptr<T>), which is kind of non-standard, but can be (as I hope I convinced you) sometimes useful.
Why would there be contention in a single threaded program?
Moving goalpost. But just to follow that thought: Decoupling alloc+init via e.g. placement-new to do this introduces a host of complications not considered in your solution.
If that layout _is_ a requirement, and you don't want a totally nonstandard foundation lib with nonstandard types promiscuously necessitating more nonstandard types, you want a std::vector+index handle.
There are alternative ways to utilize a machine with multiple cores, e.g. by running one thread per CPU core, and not sharing state between those threads; in each such thread you then have single-thread "semantics".
We were happy to use unique_ptr, however.
[0] https://chromium.googlesource.com/chromium/src/+/HEAD/base/m...
Doesn't get much glibber than that!
There is now atomic_shared_ptr which is thread safe.
In this particular case, it was subtly, Rust is preferred because it doesn't allow unsafe memory operations such as the one demonstrated. Really, all it demonstrates is that you can create really bad C++.
