C++ 多重繼承名稱查找機制深度剖析

多重繼承（MI）常因名稱查找（Name Lookup）規則導致令人困惑的「二義性」編譯錯誤。本文透過兩個經典繼承圖，深入解析 C++ 編譯器如何在靜態型別基礎上進行名稱查找、多載解析與存取檢查，釐清為何相同呼叫在不同指標型別下行為截然不同。

問題場景

圖 1：菱形繼承（共享基類 A）

C* p = new C;
p->Method_of_A(); // 編譯通過，無二義性

圖 2：獨立雙基類（B1、B2 各自繼承 A）

B4* p = new C;
p->Method_of_A(); // 編譯錯誤：ambiguous

編譯器三階段檢查流程

1. 名稱查找：從靜態型別類別開始，向基類遞迴搜尋，建立候選清單。找不到 → 「名稱未找到」。
2. 多載解析：候選清單 > 1 時，依實參型別挑選最佳匹配。無法決定 → 「二義性呼叫」。
3. 存取檢查：確認最佳候選是否可存取（private/protected）。不可存取 → 「存取違規」。

關鍵點：全程基於靜態型別（指標/參考型別），與動態物件型別無關。

圖 1 為何無二義性？

C* p = new C;
p->Method_of_A();

• 靜態型別為 C*，名稱查找僅在 C 類別內進行。
• C 已實作 Method_of_A()，候選清單僅有一個 → 直接繫結 C::Method_of_A，查找結束，完全不會搜尋到 A。

圖 2 為何報二義性？

B4* p = new C;
p->Method_of_A();

• 靜態型別為 B4*，B4 本身無 Method_of_A。
• 查找擴展至直接基類 B1、B2，各找到一個 A::Method_of_A（繼承而來）。
• 候選清單有兩個同樣簽章的函數，多載解析無法區分 → 報「二義性」。

adjustor thunk（指標調整樁碼）僅影響呼叫時的 this 指標調整，發生在名稱查找之後，非二義性成因。

解決方案

• 在 C 中提供 using B1::Method_of_A; 或 using B2::Method_of_A; 明確指定路徑。
• 在 C 重寫 Method_of_A() 統一入口（如圖 1）。
• 使用虛擬繼承共享單一 A 子物件（菱形繼承），但需注意建構/解構順序與虛基類指標開銷。
• 呼叫端強制轉型：static_cast<B1*>(p)->Method_of_A();

核心心法

「名稱查找只看靜態型別，不看動態物件；找到第一層有候選就停止，不再往上；候選多於一且無法多載解析即報二義性。」

理解此規則，即可在複雜 MI 體系中精準控制名稱可見性，避免誤判為編譯器缺陷。