Design a C++ Shared-Ownership Pointer Library

Design a small C++ shared-ownership pointer library. Explain the class interface, ownership representation, copy and move behavior, and the conditions under which the managed object is destroyed. ### Requirements and Constraints The requested task is to implement shared-pointer behavior, but the exact library surface is not specified. For a bounded exercise, assume single-threaded ownership of one object allocated for the matching type, with construction, copying, moving, assignment, reset, dereference, and an ownership-count observer. State this scope explicitly. Weak references, array ownership, custom deleters, aliasing constructors, and thread-safe reference counts are extensions to clarify rather than silently assumed requirements. ### Clarifying Questions - Which constructors and observers are required, and how is an empty pointer represented? - Must copies share one control block, and what guarantees should assignment provide if allocation fails? - Is concurrent access in scope, and does that refer to the control block, the same pointer object, or the pointed-to object? - Are cycles or weak references part of the required behavior? ```hint The object pointer alone does not identify shared ownership Two wrappers can point to the same object while maintaining unrelated counts. A correct copy needs to share the same ownership state, not just copy the raw address. ``` ### What a Strong Answer Covers - A shared control block and invariants linking the live owner count to object destruction. - Correct construction, destruction, copy, move, and assignment behavior, including self-assignment. - Empty-state and reset semantics, allocation-failure cleanup, and avoiding two ownership groups for one raw pointer. - The distinction between reference-count safety and safety of the managed object's operations. - Tests for lifetime, aliasing of owners, moves, assignment between groups, and the limits of reference counting for cycles. ### Follow-up Questions 1. Why can two independently constructed owners of the same raw pointer cause a double deletion? 2. How does a move differ from a copy in its effect on the reference count? 3. Why would atomic reference counts alone not make concurrent mutation of the pointed-to object safe?