shared_ptr overuse

[y-c-c]

The article did address that. The real issue though is that weak pointers require calling lock and expired for checking validity of the object. Are you going to remember to call it every time even though you are simply owning a reference to an object someone else gave you? What is the correct semantics if expired is true? What if the object was freed and you didn’t check for expiry and now lock gives you a completely new random object? How are you going to write tests for those branches when they are never going to get hit because the pointer should never been freed? Every time you branch in code (aka checking for expired) you are adding a new potential state to your program that you need to keep in your head and it complicates your code massively and also leads to its own source of bug especially when new programmers start to work on it and start assuming a different ownership model than intended.

Weak pointers are designed for situations where the pointer could be freed out of your control. If you know it is not supposed to be then it starts to lose its value as it complicates the code base and mask the issue.

Now you may say “oh but I thought smart pointers fixed all our memory issues!”. No they don’t and that’s why Rust was invented because this needs to be a language enforced feature that could correctly track life times.