Challenge 3: Why a Base Constructor's Virtual Call Doesn't See the Derived Override — Possible Solution ==================================================================== Per the chapter, an object's hidden vtable pointer is NOT set once, permanently, at the very start of construction -- it's updated PROGRESSIVELY, once per level of the inheritance hierarchy, as construction proceeds. Specifically: when a Derived object begins construction, the very FIRST thing that happens is the BASE class's own constructor runs -- and at that exact moment, the object's vtable pointer is set to point at the BASE class's own vtable, because as far as the currently-executing constructor is concerned, the object is only "a Base" so far; the Derived-specific parts haven't been built yet at all. Only AFTER the base constructor finishes does construction proceed to the next, more-derived level -- and at THAT point, the vtable pointer is updated again, now pointing at that level's own vtable. This process repeats, one level at a time, until the MOST-derived constructor (the actual Derived's own constructor body) finishes running -- only then does the vtable pointer finally point at the complete, final Derived vtable that a normal, fully-constructed object would have. If a virtual function is called DURING the base class's own constructor -- before this progression has completed -- the call is dispatched through WHATEVER vtable happens to be set AT THAT EXACT MOMENT, which is still the base class's own vtable, not the eventual derived one. The object hasn't "become" a Derived yet, from the vtable's own perspective, even though it eventually will be one once construction fully completes. This is exactly why the base class's own implementation runs instead of the derived override -- and why calling a PURE virtual function this way is worse than merely surprising: there IS no base-class implementation to fall back to at all, since a pure virtual function has none, making the call itself undefined behavior rather than simply "the wrong, but real, function." WHY THIS WORKS AS AN ANSWER ------------------------------ This explains the actual mechanism precisely -- the vtable pointer is updated progressively, level by level, not set once at the start -- and connects that mechanism directly to why a mid-construction virtual call sees the base's own vtable specifically, and why a PURE virtual call in that same situation has no fallback to dispatch to at all, making it genuinely undefined rather than merely unexpected.