c++ - 为什么使用 typeid 关键字是糟糕的设计？

我听说很多人说 typeid 的任何用法都是糟糕的设计，但在我看来，它似乎提供了很好的实用性。

何时(以及为什么)使用 typeid “糟糕的设计”？

什么时候可以使用 typeid？

当它不能接受，但你仍然需要类似的东西时，什么
另一种选择是有好的设计吗？

最佳答案

问题不在于 typeid 。问题是看到 typeid 会鼓励你这样写:

PolymorphicType *pType = ...;
if(typeid(*pType) == typeid(Derived1))
  pType->Func1();
else if(typeid(*pType) == typeid(Derived2))
  pType->Func2();
else if(typeid(*pType) == typeid(Derived3))
  pType->Func3();

这就是我们所说的“非常愚蠢”。这是一个以最不合理的方式完成的虚函数调用。 typeid 在用于替换 dynamic_cast 和 virtual 函数时有可能被滥用。

这个例子可能听起来很牵强。毕竟，很明显，这只是一个虚拟电话。但是糟糕的代码往往是从阻力最小的路径中生长出来的；一个人只需要做一个 typeid() == typeid() ，这个代码的种子就开始了。一般而言，如果您经常直接使用 typeid，则很有可能您正在做一些可以用其他语言结构更好地完成的事情。
typeid 是最后的多态类型推导方法。
typeid 的所有用法都是错误的吗？当然不是。 boost::any 没有它是不可能的。嗯，这是可能的，但它不会比 void* 更安全。 typeid 使类型安全的 boost::any 类型删除成为可能。它还有其他合法用途。

但是在代码行与使用比率方面，我建议它最多应该在 10,000 行代码中。比这少得多，你可能用错了。



通常，调用 typeid 的主要原因是在模板代码中(如 boost::any )或当您期望多态类型时。如果类型是静态确定的(即:给出了非多态类型的类型名或值)，那么您可以期望它在编译时完成。

您应该关注的是多态值。我看过一个性能测试，它表明一些 typeid 实现实际上遍历了类层次结构，因此它们找到类型所需的时间与实际类型和给定类型之间的类数成正比。每个实现都会不同，但这是一个很好的迹象，也许你不应该把它放在性能关键代码中。

关于c++ - 为什么使用 typeid 关键字是糟糕的设计？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/9547375/