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

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

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

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

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

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

Reflection requires some metadata about types to be stored somewhere that can be queried. Since C++ compiles to native machine code and undergoes heavy changes due to optimization, high level view of the application is pretty much lost in the process of compilation, consequently, it won't be possible to query them at run time. Java and .NET use a very high level representation in the binary code for virtual machines making this level of reflection possible. In some C++ implementations, however, there is something called Run Time Type Information (RTTI) which can be considered a stripped down version of reflection.

反射可以在c++中实现，并且已经在c++中实现过。

它不是原生的c++特性，因为它有一个沉重的成本(内存和速度)，不应该由语言默认设置——语言是“默认最大性能”导向的。

因为你不应该为你不需要的东西付钱，而且正如你自己所说，编辑器比其他应用程序更需要它，那么它应该只在你需要的地方实现，而不是“强制”到所有的代码中(你不需要对你将在编辑器或其他类似应用程序中使用的所有数据进行反思)。

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

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

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