我注意到反射是其他语言的开发人员在c中非常缺乏的一个特性.对于某些应用,我真的能明白为什么！如果您有反射,那么编写像IDE的自动完成这样的东西要容易得多.如果我们拥有它,那么序列化API肯定会变得更容易.

另一方面,c的一个主要原则是不支付你不使用的东西.这完全有道理.这是我喜欢的事情.

但在我看来可能会有妥协.为什么编译器没有为std :: type_info结构添加扩展？没有运行时开销.二进制文件可能会变得更大,但这可能是一个简单的编译器开关来启用/禁用,说实话,如果你真的担心空间节省,你可能会禁用异常和RTTI.

有些人引用模板问题,但编译器已经很高兴地为模板类型生成std :: type_info结构.

我可以想象ag开关就像-fenable-typeinfo-reflection这样可能会变得非常流行(像boost / Qt / etc这样的主流lib很容易检查生成使用它的代码,如果有的话,最终用户会受益于没有比翻转开关更多的成本).我发现这不合理,因为像这样的大型可移植库已经依赖于编译器扩展.

那么为什么这不常见呢？我想我错过了什么,这有什么技术问题？

编辑：只是一些指标重新膨胀的论点：

我查看了一个相当大的Qt项目(约45,000 LoC)并测量了metaObjects的大小.我觉得这是一个合理的指标,因为Qt moc系统是一个相当详尽的反射系统(类型,函数,枚举,成员和一些Qt特定概念,如“属性”).总共有67个元对象,所以不是一个微不足道的数量,但没有什么疯狂的,它增加了5479个字节.但是,几乎所有这些都是32字节或更少(最大的是1427字节).考虑到即使是最简单的程序,现代编译器也会生成4K以上的二进制文件,这些数字并不算太多.虽然我很想看到这样的东西应用于STL,看看它是如何展开的.

最佳答案 通常使用反射表明软件设计不佳;正确使用接口和多态就足以完成对反射所做的任何事情.如果要将额外的信息添加到std :: type_info中,它确实会导致程序膨胀.模板的问题不是你不能从它们生成std :: type_info,而是你可以获得大量的类型,因此模板的每个实例化都会产生你需要的另一个std :: type_info对象.你使用编译器开关的建议并没有真正帮助或有意义……首先,标准永远不会指定编译器开关,因为那将是特定于实现的,但假设它是这样做的…如果您想使用来自禁用了反射的库的类的反射,会发生什么？如果大多数库禁用反射 – 他们可能会这样做 – 那么它将严重限制该功能的实用程序,如果大多数库没有禁用它,那么你将在不使用它的情况下付费.