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