根据Alistair Cockburn的说法，在反射环境中不能保证子类型。

反射与潜在类型系统更相关。在c++中，你知道你得到了什么类型，你知道你可以用它做什么。

The reason C++ doesn't have reflection is that this would require the compilers to add symbol information to the object files, like what members a class type has, information about the members, about the functions and everything. This essentially would render include files useless, as information shipped by declarations would then be read from those object files (modules then). In C++, a type definition can occur multiple times in a program by including the respective headers (provided that all those definitions are the same), so it would have to be decided where to put the information about that type, just as to name one complication here. The aggressive optimization done by a C++ compiler, which can optimize out dozens of class template instantiations, is another strong point. It's possible, but as C++ is compatible to C, this would become an awkward combination.

如果你真的想了解c++的设计决策，可以找一本Ellis和Stroustrup写的《c++注释参考手册》。它并不是最新的标准，但它贯穿了最初的标准，并解释了事情是如何工作的，以及它们是如何实现的。

对于具有反射的语言来说，它是关于编译器愿意在目标代码中保留多少源代码来启用反射，以及有多少分析机制可用来解释反射的信息。除非编译器保留所有源代码，否则反射分析源代码可用事实的能力将受到限制。

c++编译器没有保留任何东西(好吧，忽略RTTI)，所以在语言中没有反射。(Java和c#编译器只保留类、方法名和返回类型，所以你只能得到一点点反射数据，但你不能检查表达式或程序结构，这意味着即使在那些“启用反射”的语言中，你能得到的信息也非常少，因此你真的不能做很多分析)。

但是您可以跳出语言，获得完整的反射功能。C语言中关于反射的另一个堆栈溢出讨论的答案讨论了这个问题。

我相信，如果c++要用作数据库访问、Web会话处理/http和GUI开发的语言，那么c++中的反射是至关重要的。缺乏反射阻碍了orm(如Hibernate或LINQ)、实例化类的XML和JSON解析器、数据序列化和许多其他东西(最初必须使用无类型数据来创建类的实例)。

可以使用软件开发人员在构建过程中可用的编译时开关 为了消除这种“一分钱一分货”的顾虑。

我是一个固件开发人员，不需要反射来从串口读取数据——那么很好，不使用交换机。但是作为一个想要继续使用c++的数据库开发人员，我经常要面对一个可怕的、难以维护的代码，这些代码在数据成员和数据库结构之间映射数据。

无论是Boost序列化还是其他机制都不能真正解决反射问题——它必须由编译器来完成——一旦完成，c++将再次在学校中教授，并用于处理数据处理的软件中

对我来说，这是问题#1(而原生线程原语是问题#2)。

反射可以是可选的，就像预处理器指令一样。类似的

#pragma启用反射

通过这种方式，我们可以两全其美，没有这个pragma库就可以在没有反射的情况下创建(没有任何开销)，然后就由个人开发人员决定他们想要的是速度还是易用性。