在c++中使用反射的情况有很多，而使用模板元编程等编译时结构无法充分解决这些问题。

N3340建议用富指针作为c++中引入反射的一种方式。除此之外，它还解决了一个问题，那就是除非你使用某个功能，否则就不用为它付费。

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

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

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

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

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

在c++中有几个关于反射的问题。

It's a lot of work to add, and the C++ committee is fairly conservative, and don't spend time on radical new features unless they're sure it'll pay off. (A suggestion for adding a module system similar to .NET assemblies has been made, and while I think there's general consensus that it'd be nice to have, it's not their top priority at the moment, and has been pushed back until well after C++0x. The motivation for this feature is to get rid of the #include system, but it would also enable at least some metadata). You don't pay for what you don't use. That's one of the must basic design philosophies underlying C++. Why should my code carry around metadata if I may never need it? Moreover, the addition of metadata may inhibit the compiler from optimizing. Why should I pay that cost in my code if I may never need that metadata? Which leads us to another big point: C++ makes very few guarantees about the compiled code. The compiler is allowed to do pretty much anything it likes, as long as the resulting functionality is what is expected. For example, your classes aren't required to actually be there. The compiler can optimize them away, inline everything they do, and it frequently does just that, because even simple template code tends to create quite a few template instantiations. The C++ standard library relies on this aggressive optimization. Functors are only performant if the overhead of instantiating and destructing the object can be optimized away. operator[] on a vector is only comparable to raw array indexing in performance because the entire operator can be inlined and thus removed entirely from the compiled code. C# and Java make a lot of guarantees about the output of the compiler. If I define a class in C#, then that class will exist in the resulting assembly. Even if I never use it. Even if all calls to its member functions could be inlined. The class has to be there, so that reflection can find it. Part of this is alleviated by C# compiling to bytecode, which means that the JIT compiler can remove class definitions and inline functions if it likes, even if the initial C# compiler can't. In C++, you only have one compiler, and it has to output efficient code. If you were allowed to inspect the metadata of a C++ executable, you'd expect to see every class it defined, which means that the compiler would have to preserve all the defined classes, even if they're not necessary. And then there are templates. Templates in C++ are nothing like generics in other languages. Every template instantiation creates a new type. std::vector<int> is a completely separate class from std::vector<float>. That adds up to a lot of different types in a entire program. What should our reflection see? The template std::vector? But how can it, since that's a source-code construct, which has no meaning at runtime? It'd have to see the separate classes std::vector<int> and std::vector<float>. And std::vector<int>::iterator and std::vector<float>::iterator, same for const_iterator and so on. And once you step into template metaprogramming, you quickly end up instantiating hundreds of templates, all of which get inlined and removed again by the compiler. They have no meaning, except as part of a compile-time metaprogram. Should all these hundreds of classes be visible to reflection? They'd have to, because otherwise our reflection would be useless, if it doesn't even guarantee that the classes I defined will actually be there. And a side problem is that the template class doesn't exist until it is instantiated. Imagine a program which uses std::vector<int>. Should our reflection system be able to see std::vector<int>::iterator? On one hand, you'd certainly expect so. It's an important class, and it's defined in terms of std::vector<int>, which does exist in the metadata. On the other hand, if the program never actually uses this iterator class template, its type will never have been instantiated, and so the compiler won't have generated the class in the first place. And it's too late to create it at runtime, since it requires access to the source code. And finally, reflection isn't quite as vital in C++ as it is in C#. The reason is again, template metaprogramming. It can't solve everything, but for many cases where you'd otherwise resort to reflection, it's possible to write a metaprogram which does the same thing at compile-time. boost::type_traits is a simple example. You want to know about type T? Check its type_traits. In C#, you'd have to fish around after its type using reflection. Reflection would still be useful for some things (the main use I can see, which metaprogramming can't easily replace, is for autogenerated serialization code), but it would carry some significant costs for C++, and it's just not necessary as often as it is in other languages.

编辑: 在回应评论时:

cdleary: Yes, debug symbols do something similar, in that they store metadata about the types used in the executable. But they also suffer from the problems I described. If you've ever tried debugging a release build, you'll know what I mean. There are large logical gaps where you created a class in the source code, which has gotten inlined away in the final code. If you were to use reflection for anything useful, you'd need it to be more reliable and consistent. As it is, types would be vanishing and disappearing almost every time you compile. You change a tiny little detail, and the compiler decides to change which types get inlined and which ones don't, as a response. How do you extract anything useful from that, when you're not even guaranteed that the most relevant types will be represented in your metadata? The type you were looking for may have been there in the last build, but now it's gone. And tomorrow, someone will check in a small innocent change to a small innocent function, which makes the type just big enough that it won't get completely inlined, so it'll be back again. That's still useful for debug symbols, but not much more than that. I'd hate trying to generate serialization code for a class under those terms.

Evan Teran: Of course these issues could be resolved. But that falls back to my point #1. It'd take a lot of work, and the C++ committee has plenty of things they feel is more important. Is the benefit of getting some limited reflection (and it would be limited) in C++ really big enough to justify focusing on that at the expense of other features? Is there really a huge benefit in adding features the core language which can already (mostly) be done through libraries and preprocessors like QT's? Perhaps, but the need is a lot less urgent than if such libraries didn't exist. For your specific suggestions though, I believe disallowing it on templates would make it completely useless. You'd be unable to use reflection on the standard library, for example. What kind of reflection wouldn't let you see a std::vector? Templates are a huge part of C++. A feature that doesn't work on templates is basically useless.

But you're right, some form of reflection could be implemented. But it'd be a major change in the language. As it is now, types are exclusively a compile-time construct. They exist for the benefit of the compiler, and nothing else. Once the code has been compiled, there are no classes. If you stretch yourself, you could argue that functions still exist, but really, all there is is a bunch of jump assembler instructions, and a lot of stack push/pop's. There's not much to go on, when adding such metadata.

但就像我说的，有一个修改编译模型的建议，添加自包含的模块，为选择的类型存储元数据，允许其他模块引用它们，而不必使用#includes。这是一个很好的开始，说实话，我很惊讶标准委员会没有因为这个改变太大而把这个提议否决掉。所以也许在5-10年后?：）

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

#pragma启用反射

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

所有的语言都不应该试图融合其他语言的所有特征。

c++本质上是一个非常非常复杂的宏汇编器。它不是(传统意义上的)c#、Java、Objective-C、Smalltalk等高级语言。

对于不同的工作有不同的工具是很好的。如果我们只有锤子，所有东西看起来都像钉子。拥有脚本语言对于某些作业是有用的，而具有反射性的oo语言(Java, Obj-C, c#)对于另一类作业是有用的，而超级高效的基本的接近机器的语言对于另一类作业是有用的(c++， C, Assembler)。

C++ does an amazing job of extending Assembler technology to incredible levels of complexity management, and abstractions to make programming larger, more complex tasks vastly more possible for human beings. But it is not necessarily a language that is the best suited for those who are approaching their problem from a strictly high-level perspective (Lisp, Smalltalk, Java, C#). If you need a language with those features to best implement a solution to your problems, then thank those who've created such languages for all of us to use!

但c++是为那些出于某种原因，需要在代码和底层机器操作之间建立强相关性的人准备的。无论是它的效率，还是编程设备驱动程序，还是与底层操作系统服务的交互，或者其他什么，c++都更适合这些任务。

C#, Java, Objective-C all require a much larger, richer runtime system to support their execution. That runtime has to be delivered to the system in question - preinstalled to support the operation of your software. And that layer has to be maintained for various target systems, customized by SOME OTHER LANGUAGE to make it work on that platform. And that middle layer - that adaptive layer between the host OS and the your code - the runtime, is almost always written in a language like C or C++ where efficiency is #1, where understanding predictably the exact interaction between software and hardware can be well understood, and manipulated to maximum gain.

我喜欢Smalltalk、Objective-C，以及拥有一个包含反射、元数据、垃圾收集等的丰富运行时系统。可以编写令人惊叹的代码来利用这些设施!但这只是堆栈上的一个更高的层，它必须依赖于更低的层，而这些层最终必须依赖于操作系统和硬件。我们总是需要一种最适合构建这一层的语言:c++ /C/Assembler。

Addendum: C++11/14 are continuing to expand C++ ability to support higher-level abstractions and systems. Threading, synchronization, precise memory models, more precise abstract machine definitions are enabling C++ developers to achieve many of the high-level abstractions that some of these high-level only languages used to have exclusive domain over, while continuing to provide close-to-metal performance and excellent predictability (i.e minimal runtime subsystems). Perhaps reflection facilities will be selectively enabled in a future revision of C++, for those who want it - or perhaps a library will provide such runtime services (maybe there is one now, or the beginnings of one in boost?).

在c++中使用反射的情况有很多，而使用模板元编程等编译时结构无法充分解决这些问题。

N3340建议用富指针作为c++中引入反射的一种方式。除此之外，它还解决了一个问题，那就是除非你使用某个功能，否则就不用为它付费。