如果编译器不“支持”RTTI，这是否意味着编译器无法处理其中包含虚函数的类层次结构？或者我是否误解了关于RTTI如何不可移植的文献，问题出在其他地方？
谢谢大家的意见！
答案 0 :(得分：13)
这可能是你正在寻找的更多答案，但这里有：
RTTI不是“可移植”意味着如果使用编译器A构建动态库A，并使用编译器B构建与A链接的应用程序B，那么就不能使用RTTI，因为编译器a和b的RTTI实现是不同的。虚函数仅受影响，因为虚函数机制也可能不是二进制兼容的。
这个问题在90年代中期非常重要，但问题现在已经过时了。并不是因为编译器现在都变得彼此二进制兼容，而是相反：C ++开发人员现在已经认识到C ++库必须作为源代码提供，而不是可链接的库。对于那些认为C ++是C语言扩展的人来说，这是非常令人不安的，但对于那些在开源环境中长大的现代程序员来说，没什么特别的。
在90年代中期和现在之间发生了什么变化，是什么构成了有价值的知识产权与什么不是知识产权之间存在着不同的态度。也就是说：实际上在USPO上注册了一个关于“表达模板”的专利。甚至这样的持有者也意识到该专利是不可行的。
C风格的“标题和二进制”库长期以来被视为混淆有价值的源代码的一种方式。越来越多的企业开始认识到，混淆更多的是自我挫败而不是保护：那里的代码很少，符合“有价值的知识产权”的地位。大多数人购买图书馆不是因为它包含特殊的IP，而是因为它更便宜而不是自己购买。事实上：应用知识产权的专业知识远比知识产权本身更有价值。但如果没有人关心这个知识产权，因为他们不知道这个，那么它就不值得了。
这就是开源的工作原理：IP是自由分配的，作为回报，这些分销商在申请该IP时获得咨询费。那些能够自己解决的人有利可图 - 对他们有好处。但这不是常态。实际上令人高兴的是，开发人员了解知识产权并在购买实施该产品的产品时出售其雇主。是的，整个“开发者社区”都建立在这个前提下。
长话短说：一旦开源运动起飞，二进制（以及随后的RTTI）兼容就像恐龙一样，同时，C ++模板库成为常态。 C ++库很久以前就变成了“仅源可分发”，比如Perl，Python，JavaScript等。为了让你的C ++编译器能够使用你用它编译的所有源代码，确保打开RTTI（包括所有C ++标准功能，例如异常） ，并且您链接的所有C ++库同样使用与编译应用程序相同的选项。
我知道有一个（也是唯一一个）编译器默认情况下不启用RTTI，这是因为还有其他传统方法可以做同样的事情。要阅读这些内容，请阅读Don Box的优秀作品“Essential COM”。
答案 1 :(得分：9)
虚拟功能不需要RTTI。
它主要用于dynamic_cast和typeid。
答案 2 :(得分：1)
RTTI中唯一不可移植的部分是从type_info::name()返回的字符串格式。
只要你能为你的编译器找到一个c++filt工具，将这样一个字符串转换成一个兼容的C ++类型，就会有一个战斗机会。
答案 3 :(得分：0)
如果编译器不“支持”RTTI，这是否意味着编译器无法处理其中包含虚函数的类层次结构？
通常所有现代C ++编译器都支持RTTI ......所以忘了它。
或者我是否误解了关于RTTI如何不便携的文献，问题出在其他地方？
RTTI今天是便携式的，适用于任何现代编译器......但有些特殊 可能会发生这种情况。
在ELF平台（Linux）下动态加载库（即dlopen）并尝试 要对库和可执行文件之间的某个类执行dynamic_cast，它可能失败 你没有传递正确的标志来链接可执行文件（-rdynamic）。
几乎所有其他案件......只是有效。