Yeah, so use shared_ptr and weak_ptr in those cases. Shared_ptr is basically equivalent to C# and Python garbage collection (loops never get collected). So that should be "good enough" for the generic case.

unique_ptr is supposed to be used in a very limited fashion as I described. Its more efficient than shared_ptr, but much much more limited.

Just to be clear, you're suggesting to use shared_ptr for every object you want to call methods that don't take "this" by move on?

(Which is not enough by any means to ensure memory safety, of course…)

Obviously, full memory safety is not ensured if you ever move over to raw pointers.

But if you're copying shared_ptrs around, the reference counting almost always ensures that the memory is valid. The idea is to rarely use references or raw-pointers unless you know you have to.

I'm not questioning how shared_ptr works. I'm claiming that using it as extensively as you describe is totally impractical, and no C++ code works this way.

I've found the UWP Windows 10 API to be using shared_ptrs and stuff more often. A lot of things are done 'correctly'.

Its mostly when interacting with legacy code (ie: MFC) where issues come up.

C++ programs written using UWP make heavy use of references, like all C++ programs, and are highly vulnerable to use after free.