Explain Weak Pointers and Sketch Shared-Pointer Control-Block Semantics

## Interview Prompt Compare C++ `unique_ptr`, `shared_ptr`, and `weak_ptr`. Explain why weak ownership exists, then sketch pseudocode for a shared-pointer control block, copying, destruction, weak locking, and final control-block cleanup. Distinguish thread-safe reference-count updates from thread-safe access to the managed object. ### Constraints & Assumptions - Strong ownership keeps the object alive; weak ownership observes without doing so. - The object is destroyed when the strong count reaches zero. - Control-block storage remains until no weak observers remain under the chosen counting convention. - The sketch must address concurrent reference-count operations but need not reproduce a standard library implementation. ### Clarifying Questions to Ask - Which weak-count convention is being used after the strong count reaches zero? - Are custom deleters and allocators in scope? - Does the design need aliasing constructors or `enable_shared_from_this`? ### What a Strong Answer Covers - Exclusive ownership and move-only behavior for `unique_ptr`. - Strong count, weak count, managed-object pointer, and deletion metadata in the control block. - Exactly-once object destruction, later control-block destruction, and race-safe weak lock. - Weak pointers breaking ownership cycles rather than merely avoiding copies. - The guarantee that control-block counts can be thread-safe while the object still requires its own synchronization. ### Follow-up Questions - How can two shared owners accidentally create two control blocks for one raw pointer? - What allocation trade-off does `make_shared` make? - How does a weak lock avoid resurrecting an object after destruction begins?