不久前，我发现一篇非常有趣的论文，关于 C++ 中 dynamic_cast 的非常简洁的性能升级：http ://www2.research.att.com/~bs/fast_dynamic_casting.pdf 。
基本上，它使 C++ 中的 dynamic_cast 比传统的继承树研究更快。如论文所述，该方法提供了一种快速、恒定时间的动态铸造算法。
这篇论文发表于 2005 年。现在，我想知道该技术是否曾经在某个地方实施过，或者是否有计划在任何地方实施？
问问题
1093 次
1 回答
8
我不知道各种编译器在 GCC 旁边使用什么实现（不是线性的）。然而，重要的是要强调，该论文并不一定提出一种方法，对于所有（甚至常见）使用而言，它总是比现有实现更快。它提出了一个通用解决方案，随着继承层次结构的增长，该解决方案逐渐变得更好。
然而，拥有大型继承层次结构很少是一个好的设计，因为它们往往会迫使应用程序变得单一且难以更改。具有灵活设计的程序往往只有层次结构，主要有 2 个级别，一个抽象基础和一个运行时多态角色的实现，以支持开放/封闭原则。在这些情况下，遍历继承图可以像单指针解引用和比较一样简单，这比 Gibbs 和 Stroustrup 提出的 index-sum-then-dereference-then-compare 更快。
此外，重要的是要强调，除非您自己的业务规则需要，否则永远不需要编写使用 dynamic_cast 的程序。使用 dynamic_cast 总是表明没有正确使用多态性并且重用受到损害。如果您需要基于构建层次结构的行为，则添加虚拟方法可以提供干净的解决方案。如果您有一个对类型进行动态转换检查的代码部分，那么该代码部分将永远不会“关闭”（在打开/关闭原则的含义中），并且需要针对添加到系统中的每个新类型进行更新。另一方面，仅在新类型上添加虚拟调度，允许您保持对扩展的开放，同时关闭在基本类型上运行的行为。
所以这确实是一个相当学术的建议（相当于在算法上将映射更改为 hash_map），如果遵循良好的设计，它不应该产生现实世界的影响。如果业务规则禁止良好的设计（某些商店可能存在代码障碍或代码所有权问题，您无法按照他们需要的方式更改现有架构，也不允许像通常用于 3rd 方库的那样构建适配器），那么最好不要根据实现的算法来决定使用哪个编译器。与往常一样，如果性能是关键，并且您必须使用 dynamic_cast 之类的功能，请分析您的代码。有可能（并且在许多情况下很可能）树遍历实现在实践中更快。
另请参阅标准委员会对实现的审查，包括 dynamic_cast和众所周知的嵌入式环境中的 c++ 和良好使用（顺便提到了 Gibbs 和 Stroustrup）。
于 2011-08-26T20:23:59.397 回答