bol*_*lov 3 c++ templates instantiation
我正在研究两个阶段名称查找.一个非常合乎逻辑的解释表明,其中一个主要原因是遵循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
}
Run Code Online (Sandbox Code Playgroud)
如果你从不写(2)程序编译并运行没有任何问题,虽然foo对于实例化是非法的X<int>.
无论你是否打过电话,我认为第(1)行应该产生错误foo.
在编写模板化类时,这可以让错过一个错误直到你最终调用有问题的方法(2),而不是在实例化模板化类(1)时得到错误.
另外,健全性检查:如果我实例化X<int>(1)但从不调用X<int>::foo(2),代码是否有效?或者它是否像"形成不良,无需诊断"?如果是后者,那么这是更早发现错误的原因.
代码有效.
此功能旨在允许简单地std::vector使用operator<或operator==编写的内容.
该运营商将试图调用<或==在它的元素,一味.如果它无效,一旦你打电话<或==打包vector它就会无法编译.
但如果你从未这样做过,vector那就行了.
现代C++会建议使用SFINAE条件方法技术或C++ 20需要条款,从而vector将仅具有一个==或<如果它是一个有效的操作.这些技术在vector设计时都不成熟,并且能够使模板类的方法无效是一个重要特征.
除了无效代码的早期失败之外,==有条件地存在允许包装代码以检测是否==可以安全地调用:古老的技术不允许这种内省.我不得不编写专门用于标准容器模板的自定义特征,以检测是否<可以安全地调用至少一个案例.
| 归档时间: |
|
| 查看次数: |
58 次 |
| 最近记录: |