在过去的10年里，人们一直在尝试向c++中添加反射。最新的提案是针对c++23的，可能会，也可能不会。

与大多数语言中的反射不同，c++反射的计划是编译时反射。所以在编译时，你可以反射结构成员、函数和方法参数和属性、枚举值和名称等。

然后，您可以进行有限的具体化，注入关于反射的信息以生成其他类型和代码。

虽然这有点奇怪，但这意味着不使用反射的程序不会为它支付运行时成本。它也非常强大。

最简单的例子是，您可以使用它来实现运行时反射。

struct Member {
  std::string_view name;
  std::any_ref value;
};

struct Reflectable {
  virtual std::span<Member> GetMembers() const = 0;
  virtual std::span<Member> GetMembers() = 0;
};

template<class D>
struct ImplReflectable:Reflectable {
  std::span<Member> GetMembers() const final;
  std::span<Member> GetMembers() final;
};
template<class D>
std::span<Member> ImplReflectable<D>::GetMembers() const {
  // compile time reflection code on D here
}
template<class D>
std::span<Member> ImplReflectable<D>::GetMembers() {
  // compile time reflection code on D here
}

你把上面的代码写了一次，突然你就可以对任何你想要反射的类型，你可以这样做:

struct Point : ImplReflectable<Point> {
  int x, y;
};

和一个反射系统连接到点。

实现此运行时反射的库可以像您喜欢的那样复杂和强大。每种类型都必须做一些工作(如上所述)才能选择加入，但对于UI库(例如)这样做并不是一个严重的问题。没有选择的类型延续了c++的假设:“如果你不使用它，就不要为它付费”。

但这仅仅是个开始。一个提议，元类，允许:

interface Reflectable {
  std::span<Member> GetMembers() const;
  std::span<Member> GetMembers();
};

您可以使用元类或接受类型并返回类型的函数。这允许您定义类的元类，如“interface”，用语言编写。现在，接口有点像玩具，但是你可以编写QObject或Reflectable或PolymorphicValueType或NetworkProtocol元类来修改你的类定义的含义。

这可能会也可能不会出现在c++23中。它会继续变得更好，但也会继续被推回去。对于大多数主要的c++编译器，您可以尝试多种编译时反射实现。语法是不断变化的，因为有基于符号运算符的反射库，基于reflexpr的运算符反射库，其中一些反射数据是类型，另一些是constexpr对象和consteval函数。

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

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

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

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

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

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

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

如果c++可以:

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

这足以在无类型数据处理的关键处创建非常容易使用的库，而无类型数据处理在当今的web和数据库应用程序中非常普遍 (所有的orm，消息传递机制，xml/json解析器，数据序列化等)。

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

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

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

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

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

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

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

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