快速动态铸造进度

Question

不久之前,我发现了一篇非常有趣的论文,关于C++中dynamic_cast的非常整洁的性能升级:http://www2.research.att.com/~bs/fast_dynamic_casting.pdf.

基本上,它使得C++中的dynamic_cast比继承树中的传统研究更快.如该论文所述,该方法提供了快速,恒定时间的动态铸造算法.

本文发表于2005年.现在,我想知道这项技术是否曾在某处实施过,或者是否有计划在任何地方实施？

Answer 1

我不知道各种编译器在GCC旁边使用了什么实现(不是线性的).然而,重要的是要强调该论文不一定提出一种方法,该方法总是比现有实现(对于所有(甚至常见的))使用更快.它提出了一种通用的解决方案,随着继承层次结构的增长而逐渐变得更为渐进.

但是,拥有大型继承层次结构很少是一个好的设计,因为它们往往会迫使应用程序变得单一且不灵活.具有灵活设计的程序往往只有层次结构,主要有2个级别,抽象基础和运行时多态角色的实现,以支持开放/封闭原则.在这些情况下,遍历继承图可以像单个指针解除引用和比较一样简单,这可能比Gibbs和Stroustrup提供的index-sum-then-dereference-then-compare更快.

此外,重要的是要强调,除非您自己的业务规则需要,否则永远不必编写使用dynamic_cast的程序.dynamic_cast的使用总是表明多态性未被正确使用并且重用被破坏.如果您需要基于强制层次结构的行为,则添加虚拟方法可提供干净的解决方案.如果您有一个对类型进行dynamic_cast检查的代码部分,则该部分代码将永远不会"关闭"(在开放/封闭原则的意义上),并且需要针对添加到系统的每个新类型进行更新.另一方面,虚拟分派仅在新类型上添加,允许您保持对扩展的开放性,同时关闭在基本类型上运行的行为.

因此,如果遵循良好的设计,这实际上是一个相当学术性的建议(等同于将地图更改为hash_map算法),不应该具有真实世界效果.如果业务规则禁止良好的设计(某些商店可能存在代码障碍或代码所有权问题,您无法以他们需要的方式更改现有体系结构,也不允许按照通常用于第三方库的方式构建适配器),那么最好不要根据实现的算法决定使用哪个编译器.与往常一样,如果性能是关键,并且您必须使用像dynamic_cast这样的功能,请对代码进行概要分析.有可能(并且可能在许多情况下)树木实施在实践中更快.

另请参阅标准委员会对实现的评论,包括dynamic_cast和嵌入式环境中熟知的c ++外观以及良好的使用(其中提到了Gibbs和Stroustrup).