C++ 为什么C++没有反射？

Why does C++ not have reflection?

提问by amit

This is a somewhat bizarre question. My objectives are to understand the language design decision and to identify the possibilities of reflection in C++.

这是一个有点奇怪的问题。我的目标是了解语言设计决策并确定 C++ 中反射的可能性。

1. Why C++ language committee did not go towards implementing reflection in the language? Is reflection too difficult in a language that does not run on a virtual machine (like java)?

2. If one were to implement reflection for C++, what will be the challenges?

1. 为什么 C++ 语言委员会没有在语言中实现反射？使用不在虚拟机上运行的语言（如 java）进行反射是否太难了？

2. 如果要为 C++ 实现反射，将面临哪些挑战？

I guess the uses of reflection are well-known: editors can be more easily written, program code will be smaller, mocks can be generated for unit tests and so on. But it would be great if you could comment on uses of reflection too.

我想反射的用途是众所周知的：编辑器可以更容易编写，程序代码会更小，可以为单元测试生成模拟等等。但是，如果您也可以评论反射的使用，那就太好了。

回答by jalf

There are several problems with reflection in C++.

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 #includesystem, 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 veryfew 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 relieson 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 existin 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 canremove 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 newtype. 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 templatestd::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>::iteratorand std::vector<float>::iterator, same for const_iteratorand 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 doesexist in the metadata. On the other hand, if the program never actually usesthis 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_traitsis 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.

• 要添加很多工作，而且 C++ 委员会相当保守，除非他们确定会得到回报，否则不要花时间在激进的新功能上。（已经提出了添加类似于 .NET 程序集的模块系统的建议，虽然我认为人们普遍认为拥有它会很好，但目前这不是他们的首要任务，并且已被推迟到很久之后C++0x。这个特性的动机是摆脱#include系统，但它也至少会启用一些元数据）。

• 您不会为不使用的东西付费。这是 C++ 基础必须的基本设计理念之一。如果我可能永远不需要元数据，为什么我的代码要携带元数据？此外，元数据的添加可能会阻止编译器进行优化。如果我可能永远不需要元数据，我为什么要在我的代码中支付这笔费用？

• 这使我们再大点：C ++做很对编译的代码很少保证。编译器几乎可以做任何它喜欢的事情，只要产生的功能是预期的。例如，您的课程实际上不需要 在那里。编译器可以优化它们，内联它们所做的一切，而且它经常这样做，因为即使是简单的模板代码也往往会创建相当多的模板实例。C++ 标准库依赖于这种积极的优化。只有当实例化和销毁对象的开销可以被优化掉时，函子才是高性能的。 operator[]向量上的性能只能与原始数组索引相媲美，因为可以内联整个运算符，从而完全从编译代码中删除。C# 和 Java 对编译器的输出做了很多保证。如果我在 C# 中定义一个类，那么该类将存在于生成的程序集中。即使我从不使用它。即使对其成员函数的所有调用都可以内联。类必须在那里，以便反射可以找到它。C# 编译为字节码可以缓解部分这种情况，这意味着 JIT 编译器可以如果愿意，可以删除类定义和内联函数，即使最初的 C# 编译器不能。在 C++ 中，你只有一个编译器，它必须输出高效的代码。如果允许您检查 C++ 可执行文件的元数据，您会希望看到它定义的每个类，这意味着编译器必须保留所有定义的类，即使它们不是必需的。

• 然后是模板。C++ 中的模板与其他语言中的泛型完全不同。每个模板实例化都会创建一个 新类型。std::vector<int>是一个完全独立的类 std::vector<float>。这在整个程序中加起来就有很多不同的类型。我们的反思应该看到什么？该模板std::vector？但是，因为这是一个源代码结构，在运行时没有任何意义，这怎么可能呢？它必须看到单独的类 std::vector<int>和 std::vector<float>. 和 std::vector<int>::iterator和 std::vector<float>::iterator，同为const_iterator等等。一旦您进入模板元编程，您很快就会实例化数百个模板，所有这些模板都会被编译器内联并再次删除。除了作为编译时元程序的一部分之外，它们没有任何意义。所有这数百个类都应该对反射可见吗？他们必须这样做，否则我们的反射将毫无用处，如果它甚至不能保证我定义的类实际上会在那里。一个附带问题是模板类在实例化之前不存在。想象一个使用std::vector<int>. 我们的反射系统应该能够看到std::vector<int>::iterator吗？一方面，您肯定会如此期待。这是一个重要的类，它是根据 定义的std::vector<int>，它确实存在于元数据中。另一方面，如果程序从来没有真正使用过这个迭代器类模板，它的类型就永远不会被实例化，所以编译器一开始就不会生成这个类。在运行时创建它为时已晚，因为它需要访问源代码。

• 最后，反射在 C++ 中并不像在 C# 中那么重要。原因又是模板元编程。它不能解决所有问题，但在许多情况下，您可能会求助于反射，因此可以编写一个在编译时执行相同操作的元程序。 boost::type_traits是一个简单的例子。你想知道 type T吗？检查其type_traits. 在 C# 中，您必须使用反射在其类型之后四处钓鱼。反射对于某些事情仍然有用（我可以看到，元编程不能轻易替代的主要用途是用于自动生成的序列化代码），但它会为 C++ 带来一些巨大的成本，而且它并不像它那样频繁是其他语言。

Edit:In response to comments:

编辑：回应评论：

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.

cdleary：是的，调试符号做了类似的事情，因为它们存储有关可执行文件中使用的类型的元数据。但他们也遭受我所描述的问题。如果您曾经尝试过调试发布版本，您就会明白我的意思。在源代码中创建类的地方存在很大的逻辑空白，该类已被内联到最终代码中。如果您要将反射用于任何有用的事情，您需要它更可靠和一致。事实上，几乎每次编译时类型都会消失。您更改了一个很小的细节，作为响应，编译器决定更改哪些类型被内联，哪些类型没有。你如何从中提取任何有用的东西，当你 甚至不能保证最相关的类型将在您的元数据中表示？您正在寻找的类型可能在上次构建中已经存在，但现在已经消失了。明天，有人会检查一个小的无害的更改到一个无害的小函数，这使得类型足够大以至于它不会被完全内联，所以它会再次回来。这对于调试符号仍然有用，但仅此而已。我讨厌尝试根据这些条款为类生成序列化代码。但仅此而已。我讨厌尝试根据这些条款为类生成序列化代码。但仅此而已。我讨厌尝试根据这些条款为类生成序列化代码。

Evan Teran: Of course these issues couldbe 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 hugepart of C++. A feature that doesn't work on templates is basically useless.

埃文·特兰：当然，这些问题可以得到解决。但这又回到了我的观点#1。这需要大量的工作，而且 C++ 委员会有很多他们认为更重要的事情。在 C++ 中获得一些有限的反射（并且会是有限的）的好处是否真的足够大以证明以牺牲其他功能为代价来专注于它？添加核心语言的功能是否真的有巨大的好处，这些功能已经（大部分）可以通过库和预处理器（如 QT 的）来完成？也许吧，但与不存在此类库时相比，需求要小得多。不过，对于您的具体建议，我相信在模板上禁止它会使它完全无用。例如，您将无法在标准库上使用反射。什么样的反思不会std::vector? 模板是C++的重要组成部分。对模板不起作用的功能基本上是无用的。

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 areno 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.

但是你是对的，可以实现某种形式的反射。但这将是语言的重大变化。就像现在一样，类型只是一个编译时构造。它们的存在是为了编译器的利益，没有别的。一旦代码被编译，也都没有课。如果你伸展自己，你可能会争辩说函数仍然存在，但实际上，只有一堆跳转汇编指令，以及很多堆栈推送/弹出。添加此类元数据时，没什么可做的。

But like I said, there is a proposal for changes to the compilation model, adding self-contained modules, storing metadata for select types, allowing other modules to reference them without having to mess with #includes. That's a good start, and to be honest, I'm surprised the standard committee didn't just throw the proposal out for being too big a change. So perhaps in 5-10 years? :)

但是就像我说的，有一个修改编译模型的提议，添加自包含模块，存储选择类型的元数据，允许其他模块引用它们而不必弄乱#includes。这是一个好的开始，老实说，我很惊讶标准委员会并没有因为提案的变化太大而将其抛弃。那么也许在 5-10 年内？:)

回答by Mehrdad Afshari

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++ 编译为本地机器代码并因优化而发生重大变化，因此在编译过程中几乎丢失了应用程序的高级视图，因此无法在运行时查询它们。Java 和 .NET 在虚拟机的二进制代码中使用非常高级的表示，使这种级别的反射成为可能。然而，在一些 C++ 实现中，有一种叫做运行时类型信息 (RTTI) 的东西，它可以被认为是反射的精简版本。

回答by Mordachai

All languages should not try to incorporate every feature of every other language.

所有语言都不应该试图结合其他所有语言的所有功能。

C++ is essentially a very, very sophisticated macro assembler. It is NOT (in a traditional sense) a high-level language like C#, Java, Objective-C, Smalltalk, etc.

C++ 本质上是一个非常非常复杂的宏汇编程序。它不是（传统意义上的）高级语言，如 C#、Java、Objective-C、Smalltalk 等。

It is good to have different tools for different jobs. If we only have hammers, all things are going to look like nails, etc. Having script languages is useful for some jobs, and reflective OO-languages (Java, Obj-C, C#) are useful for another class of jobs, and super-efficient bare-bones close-to-the-machine languages are useful for yet another class of jobs (C++, C, Assembler).

为不同的工作配备不同的工具是很好的。如果我们只有锤子，那么所有的东西都会看起来像钉子，等等。脚本语言对某些工作很有用，反射 OO 语言（Java、Obj-C、C#）对另一类工作很有用，超级- 高效的准机器语言对于另一类工作（C++、C、汇编程序）很有用。

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++ 在将汇编器技术扩展到令人难以置信的复杂性管理水平和抽象方面做了一项了不起的工作，使编程更大、更复杂的任务对人类来说更有可能。但它不一定是最适合从严格的高级角度（Lisp、Smalltalk、Java、C#）解决问题的人的语言。如果您需要一种具有这些功能的语言来最好地实现您的问题的解决方案，那么感谢那些为我们所有人创建此类语言的人！

But C++ is for those who, for whatever reason(s), need to have a strong correlation between their code and the underlying machine's operation. Whether its efficiency, or programming device drivers, or interaction with the lower-level OS services, or whatever, C++ is better suited to those tasks.

但是 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.

C#、Java、Objective-C 都需要一个更大、更丰富的运行时系统来支持它们的执行。该运行时必须交付给相关系统 - 预先安装以支持您的软件运行。并且必须为各种目标系统维护该层，由其他语言定制以使其在该平台上工作。中间层 - 主机操作系统和您的代码之间的自适应层 - 运行时，几乎总是用 C 或 C++ 之类的语言编写，其中效率是第一，可以很好地理解软件和硬件之间的准确交互。理解并操纵以获得最大收益。

I love Smalltalk, Objective-C, and having a rich runtime system with reflection, meta-data, garbage collection, etc. Amazing code can be written to take advantage of these facilities! But that's simply a higher layer on the stack, a layer that must rest on lower layers, that themselves must ultimately sit upon the OS and the hardware. And we will always need a language that is best suited for building that layer: C++/C/Assembler.

我喜欢 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++11/14 正在继续扩展 C++ 的能力以支持更高级别的抽象和系统。线程、同步、精确的内存模型、更精确的抽象机器定义使 C++ 开发人员能够实现许多高级抽象，这些高级抽象中的一些曾经拥有独占域，同时继续提供接近-金属性能和出色的可预测性（即最小运行时间子系统）。也许反射设施将在 C++ 的未来修订版中选择性地启用，对于那些想要它的人 - 或者也许一个库将提供这样的运行时服务（也许现在有一个，或者一个开始在 boost 中？）。

回答by Michael Kohne

If you really want to understand the design decisions surrounding C++, find a copy of the The Annotated C++ Reference Manualby Ellis and Stroustrup. It's NOT up to date with the latest standard, but it goes through the original standard and explains how things work and often, how they got that way.

如果您真的想了解围绕 C++ 的设计决策，请找到Ellis 和 Stroustrup的The Annotated C++ Reference Manual的副本。它不是最新的标准，但它通过了原始标准并解释了事情是如何运作的，以及他们是如何做到这一点的。

回答by Ira Baxter

Reflection for languages that have it is about how much of the source code the compiler is willing to leave in your object code to enable reflection, and how much analysis machinery is available to interpret that reflected information. Unless the compiler keeps all the source code around, reflection will be limited in its ability to analyze the available facts about the source code.

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

The C++ compiler doesn't keep anything around (well, ignoring RTTI), so you don't get reflection inthe language. (Java and C# compilers only keep class, method names and return types around, so you get a little bit of reflection data, but you can't inspect expressions or program structure, and that means even in those "reflection-enabled" languages the information you can get is pretty sparse and consequently you really can't do much analysis).

C++ 编译器不会保留任何内容（好吧，忽略 RTTI），因此您不会在语言中获得反射。（Java 和 C# 编译器只保留类、方法名称和返回类型，因此您可以获得一点反射数据，但您无法检查表达式或程序结构，这意味着即使在那些“启用反射”的语言中您可以获得的信息非常稀少，因此您确实无法进行太多分析）。

But you can step outsidethe language and get full reflection capabilities. The answer to another stack overflow discussion on reflection in Cdiscusses this.

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

回答by Klaim

Reflection can be and has been implemented in c++ before.

反射可以并且已经在 C++ 中实现。

It is not a native c++ feature because it have an heavy cost (memory and speed) that should'nt be set by default by the language - the language is "maximum performance by default" oriented.

它不是本机 c++ 功能，因为它具有沉重的成本（内存和速度），默认情况下不应由语言设置 - 该语言是“默认情况下最大性能”导向的。

As you shouldn't pay for what you don't need, and as yous say yourself it's needed more in editors than in other applications, then it should be implemented only where you need it, and not "forced" to all the code (you don't need reflection on all the data you'll work with in a editor or other similar application).

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

回答by Johannes Schaub - litb

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++ 没有反射的原因是，这将要求编译器向目标文件添加符号信息，例如类类型具有哪些成员、关于成员的信息、关于函数的信息等等。这本质上会使包含文件变得无用，因为声明传送的信息将从这些目标文件（然后是模块）中读取。在 C++ 中，类型定义可以通过包含相应的头文件在程序中多次出现（假设所有这些定义都相同），因此必须决定将有关该类型的信息放在哪里，就像命名一个复杂在这里。C++ 编译器进行的积极优化可以优化数十个类模板实例，这是另一个优点。这是可能的，但由于 C++ 与 C 兼容，

回答by pong

There are tons of cases for using reflection in C++ that cannot be adequately addressed using compile time constructs like template meta-programming.

有很多在 C++ 中使用反射的情况，使用模板元编程等编译时构造无法充分解决。

N3340proposes rich pointers as a way to introduce reflection in C++. Among other things it addresses the issue of not paying for a feature unless you use it.

N3340提出了丰富的指针作为在 C++ 中引入反射的一种方式。除其他外，它解决了除非您使用某个功能，否则不为该功能付费的问题。

回答by user1401491

Reflection could be optional, like a preprocessor directive. Something like

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

#pragma enable reflection

#pragma enable reflection

That way we can have the best of both worlds, with out this pragma libraries would be created without reflection (without any overheads as discussed), then it would be up the individual developer whether they want speed or ease of use.

这样我们就可以两全其美，没有这个 pragma 库将在没有反射的情况下创建（没有讨论的任何开销），那么个人开发人员是否想要速度或易用性将取决于他们。

回答by user1401491

If C++ could have:

如果 C++ 可以：

• class member data for variable names, variable types, and the constmodifier
• a function arguments iterator (only position instead of name)
• class member data for function names, return type, and the constmodifier
• list of parent classes (in the same order as defined)
• data for template members and parent classes; the expanded template (meaning the actual type would be available for the reflection API and not the 'template information of how to get there')

• 变量名称、变量类型和const修饰符的类成员数据
• 函数参数迭代器（仅位置而不是名称）
• 函数名称、返回类型和const修饰符的类成员数据
• 父类列表（与定义的顺序相同）
• 模板成员和父类的数据；扩展模板（意味着实际类型可用于反射 API 而不是“如何到达那里的模板信息”）

That would be enough to create very easy to use libraries at the crux of the typeless data processing that is so prevalent in today's web and database applications (all the orms, messaging mechanisms, xml/json parsers, data serialization, etc).

这足以在当今 Web 和数据库应用程序（所有 orms、消息传递机制、xml/json 解析器、数据序列化等）中非常普遍的无类型数据处理的关键处创建非常易于使用的库。

For example, the basic information supported by the Q_PROPERTYmacro (part of Qt Framework) http://qt.nokia.com/doc/4.5/properties.htmlexpanded to cover class methods and e) - would be extraordinary beneficial to C++ and to the software community in general.

例如，Q_PROPERTY宏支持的基本信息（Qt 框架的一部分） http://qt.nokia.com/doc/4.5/properties.html扩展到涵盖类方法和 e) - 对 C++ 和一般的软件社区。

Certainly the reflection I am referring to would not cover the semantic meaning or more complex issues (like comments source code line numbers, data flow analysis, etc) - but neither do I think those are needed to be part of a language standard.

当然，我所指的反射不会涵盖语义或更复杂的问题（如注释源代码行号、数据流分析等）——但我也不认为这些都需要成为语言标准的一部分。