實例化模板類的格式化非模板化方法

Question

我正在研究兩個階段名稱查找 。 一個非常合乎邏輯的解釋表明， 其中一個主要原因是遵循C ++哲學盡早捕獲錯誤 。

我的問題是為什么這種哲學不遵循非模板化方法。 而不是檢查何時以及是否調用該方法，為什么不在實例化模板化類時檢查階段2中的所有非模板化方法？

例如：

template <class T>
struct X {

  auto foo() // non-templated (important)
  {
    T t{};
    return t.non_existing();
  }
};

int main()
{
  X<int> x; // (1) this compiles OK.

  // somewhere is a galaxy far far away,
  // maybe deep inside some unrelated code
  x.foo();  // (2) the error is here
}

如果你從不寫（2）程序編譯並運行沒有任何問題，雖然foo對於實例化的X<int>是非法的。

無論你是否曾經調用foo ，我認為第（1）行應該會產生錯誤。

在編寫模板化類時，這可以讓錯過一個錯誤直到你最終調用有問題的方法（2），而不是在實例化模板化類（1）時得到錯誤。

另外，健全性檢查：如果我實例化X<int> （1）但從不調用X<int>::foo （2），代碼是否有效？ 或者它是否像“形成不良，無需診斷”？ 如果是后者，那么這是更早發現錯誤的原因。

Answer 1

代碼有效。

此功能旨在允許像std::vector這樣的東西，只需簡單地編寫operator<或operator== 。

這個運算符會盲目地嘗試在其元素上調用<或== 。 如果它無效，一旦在包裝vector上調用<或== ，它將無法編譯。

但如果你從未這樣做過，那么vector就可以了。

現代C ++會建議使用SFINAE條件方法技術或C ++ 20需要條款，從而vector將僅具有一個==或<如果它是一個有效的操作。 在設計vector時，這些技術都不成熟，並且具有無效模板類方法的能力是一個重要特征。

除了無效代碼的早期失敗之外，有條件存在==允許包裝代碼以檢測==是否可以安全地調用：古老的技術不允許這種內省。 我不得不編寫專門用於標准容器模板的自定義特征，以檢測<至少在一個案例中是否可以安全調用< 。