Challenge 2: Why std::vector Would Break the Capstone's Design — Possible Solution ==================================================================== Storing shapes as std::vector means every element in the vector is a plain Shape OBJECT, stored BY VALUE, with a fixed, uniform size determined by Shape's own definition alone. The moment a Circle or Rectangle object is inserted into such a vector -- e.g. via shapes.push_back(someCircle) -- the insertion itself performs a by-value COPY into a Shape-typed slot, which per cpp3-5's own object slicing material "slices off" every part of the object beyond what Shape itself defines: Circle's own radius member, and critically, Circle's own override of area() (accessible only through Circle's distinct vtable) are both discarded entirely. What actually ends up stored in the vector is a plain, generic Shape -- not a Circle, not a Rectangle, indistinguishable from every other sliced shape, and its area() call would always resolve to Shape's own base implementation (returning 0, per this chapter's own base-class stub), never the derived, shape-specific calculation the whole capstone depends on. The capstone's entire point -- a heterogeneous collection of DIFFERENT shape types, each computing its OWN correct area via virtual dispatch -- would be silently destroyed by this change. Every shape in the inventory would report an area of 0 (or whatever Shape's own base stub returns), with no compile error, no warning, and no visible indication that anything had gone wrong -- exactly the "slicing compiles silently" danger cpp3-5's own warn-box describes. std::vector>, by contrast, never stores a Shape object directly at all -- it stores POINTERS (specifically, ownership-managing smart pointers) to heap-allocated Circle/Rectangle objects. Since a Circle allocated on the heap and referenced through a unique_ptr is never copied into a Shape-sized slot at any point, its full Circle-specific data and its own vtable remain completely intact, and virtual dispatch through that pointer correctly reaches Circle's own area() every time. WHY THIS WORKS AS AN ANSWER ------------------------------ This traces the concrete mechanism of the breakage (a by-value push_back triggering slicing on every insertion) and its concrete symptom (every shape silently reporting area 0), directly tying the explanation to cpp3-5's own slicing material rather than a vague "it wouldn't work," and explains precisely why unique_ptr avoids the problem structurally.