为什么要用反射java_Java为什么要有反射机制，而 C++ 没有？

c++中由typeid返回来的垃圾type_info除了表明俺大c++也支持运行时类型识别了，，就一点鬼用都没有了。它仅仅能够为对象的类型给出一个唯一的id，这是必须满足的最基本功能，而且这个id，在有动态库的情况下，还不是唯一，也就是动态库typeif(int)和应用程序的typeid(int)，两边的结果可能还不一样。type_info里面仅有type的名字描述，任何多余的一点点信息，全部都没有，没有字段信息，没有方法信息，没有基类信息，……，更别说添加用户自定义的反射信息，好比C#的attribute或者java的标记。当然，真要说type_info完全一无是处，也有些过分了，起码，标准库的好些组件还用了type_info，只是，但凡大c++中只要用上一点点高级一点关于反射的运用，没有一个会在极简版的type_info上做文章，无一不重起炉灶，自力更生，自造一只c++下的反射轮子。

但是，c++下的反射长成这个小样子，并不意味着残次品type_info就完全满足c++的代码了。序列化，对象与json数据直接互相转换，运行时类型计算等等，都离不开反射呢，所有必须反射大放异彩的场合或者应用，比如orm，比如gui等，c++类库都做得很难看，也很不好用。别的不说，就说printf里面的%d, %f, %s这些鬼符号的出现，都是因为反射的缺席才搞得这么难看，所以要猿猴提供类型信息。看看c#下的{N}，多统一啊！所以说，反射这个东西，不由语言的意志决定，语言在反射上做不好，反射就会以各种各样的形式出现来折磨语言的猿猴。反射可以理解为一个类型全部运行信息的唯一集中之场所，通过这个元对象，猿猴可以从中提取其类型的一切信息，对象的大小，构造函数，对象所支持的接口，对象类型与其他类型的关系，等等。所以说，反射是必需品，不可或缺。

但是，稍作思考，就可以得出结论，在语言层面上，c++对于反射的支持，还真的只能给出这么一个极简版的极残次品反射方案，它不会也不能提供更高级一点的反射功能了，哪怕一点点。

首先说不会，根本原因是c++的基本哲学，零抽象，不为不用到的功能付出任何代价，不管这个代价有多小。java或者C#下的反射，会登记类型的一切信息，全部的字段信息，全部的方法信息，全部的接口信息等，不管猿猴是否需要，反正就全部都要备案。甚至，java或者c#，对于任何一个类，包括临时辅助类，压根就不可能需要反射，都会一一备案。这种有备无患的态度，向来为c++所不齿。虽然保存这些元信息数据，也花不了多少内存。但大c++就坚决杜绝这些不良作风。好像java、C#的反射处理方法太过铺张浪费，但是，好像还真除了这么玩之外，就没有更好的选择了。另外，这里废话一句题外话，任何c++下的设计，必须坚守零抽象的基本原则，否则一定是错误的设计。C++下，语言层面上可以只在必要的时候(比如带有虚函数的类型，比如使用了typeid语言)，编译器才生成必要type_info对象。但是，一生成type_info里面还要带上全部的字段信息方法信息，这些就没法零抽象了。

然后是不能。这个是程度的问题，就是说，反射要提供多少信息，而这些信息，自然要有相应的数据结构来存储，好比数组，好比链表，好比字符串(unicode字符编码)，好比哈希表等，这些鬼怪，c++语言层面上还真无法很好的提供。另外，c++还有一个大哲学，完备。不仅仅简单类型要很好地支持反射，复杂类型也要支持反射啊，比如多继承，虚继承，模板也要有完善的反射啊(至今为止，java好像还不支持模板类型的反射)，这些考虑起来，c++下要在语言层面上直接支持高级一点点的反射，自然就很吃力不讨好，简直不可能。

但是，c++语言层面上无法搞反射，并不意味着c++下就搞不好反射，对于c++来说，一切皆有可能，任何其他语言的特性，都可以用种种匪夷所思的奇技淫巧来一一实现，当然，有些就模拟得的确不咋样。但是反射，通过库的形式，c++也可以做得很完备，可以比java或C#的反射还好用，不仅仅可以attribute，还可以添加其他各种各样的用户自定义信息。至于字段信息，方法信息，接口信息这些必需品，就更不用说了。而且，还支持模板的反射。The End！