重大变更（一）：关于C++26的十大猜想

你好，我是卢誉声。

在上一讲中，我们讨论了C++23带来的变化。由于C++23已经是冻结特性，所以我们讨论得非常具体。C++23作为“更好的C++20”，其本质是针对C++20进行改进和修补，所以涵盖的内容比较有限。

但是，作为继C++20之后的又一重大标准变更，C++26及其后续演进将会给我们带来诸多重量级特性。为了更好地理解C++标准的演进思路、掌握C++标准演进的底层逻辑，并一窥未来的变化，这一讲中，我们把视角转向C++26及其后续演进。

不过，由于C++26还处在提案阶段。所以，我们只能预测一下那些“大概率会进入C++26”的特性，也许其中一些特性会被推迟或发生改变，但并不影响我们分析C++标准演进的底层逻辑和未来。

好，就让我们从静态反射开始今天的内容。

静态反射

静态反射（static reflection），很有可能是C++26中即将引入的最为重量级的特性。但凡是了解何为反射机制，同时熟悉C++的人，看到这个特性时，估计会虎躯一震——什么？C++要支持反射？

但是我们需要冷静一下，这个特性的定语很重要，这个反射是“静态的”（static）。

对于反射的概念，还是很容易理解的，就是编程语言提供一套机制，帮助开发者在代码中获取类型的相关信息，比如类型名称、大小、类的成员、函数参数信息等等。它允许开发者在代码中，根据反射信息执行相应的操作，这让语言变得更加“动态”——也就是根据反射信息来确定代码如何执行。

其实早在C++98标准，在引入dynamic_cast和RTTI时，C++就允许开发者获取有限的运行时类型信息。但是，这些运行时类型信息非常贫乏，除了支持类型转换以外，并没有什么其他用处。而且，即便是这些有限的功能，也特别耗费C++的运行时资源，与C++自身的设计理念有些偏差。

不过，C++新提出的静态反射则大不相同。这个特性秉持了现代C++一以贯之的理念，在编译时获取并确定所有信息。所以说，这个静态反射也就和C++11之后引入的type_traits一样，可以在编译时获取所有的信息。并在编译时，通过模板和constexpr等方式完成相关计算。

静态反射标准的特性尚处于讨论阶段，不过已经有相关的TS（Technical specifications，即技术规范）。因此，我们来了解一下，在TS中是如何使用静态反射的？

首先，C++会提供一个新的关键字——reflexpr，用于获取一个符号的“元数据”。我们可以结合后面这个例子来理解。

#include <cstdint>
#include <experimental/reflect>
 
int main() {
    int32_t num = 0;
    
    using NumMeta = reflexpr(num);
 
    return 0;
}

你不用尝试运行这个例子——目前暂时还没有编译器支持它。我们关注点就在代码第7行，通过reflexpr获取了num的元数据。

我们需要知道，reflexpr返回的元数据并不是一个变量，而是一个类型，所以要用using或者typedef来为其定义一个别名，这样才能在后面使用。

那么获取到的类型别名要如何使用呢？我们继续看代码。

#include <string>
#include <iostream>
#include <experimental/reflect>
 
int main() {
    using Type1 = reflexpr(std::string);
    using Type2 = reflexpr(std::u8string);
 
    std::cout << std::experimental::reflect::get_name_v<Type2> << std::endl;
    static_assert(Type1 == "basic_string");
 
    std::cout << std::experimental::reflect::reflects_same_v<Type1, Type2> << std::endl;
 
    return 0;
}

获取到类型别名后，我们就可以使用C++提供的reflect工具函数，静态地获取关于类型别名的一切信息，比如代码第9行通过get_name_v获取了Type2的类型名称，第12行通过reflects_same_v判断两个类型是否相同。

由于静态反射的类型信息都存储在类型中，因此，reflect的工具都可以实现成工具类型或constexpr函数。所以，我们也可以在static_assert和模板参数中，配合C++ Concepts特性，通过模板实现针对不同类型细节执行不同的操作逻辑。

事实上，正是因为静态反射需要基于constexpr、static_assert和concept实现。因此，直到C++26之后，静态反射才可能成为备选的提案。

基于这些基础设施，C++的编译时计算会变得前所未有的强大。

此外，静态反射的TS还提供了面向反射元数据类型的一系列concept，这样我们就可以通过定义模板函数，完成更多的反射元数据的计算与判断。

可以说，如果C++26及其后续演进真的实现了静态反射TS，C++的编译器“动态”特性就基本完美了。

异步任务框架

从C++11开始，现代C++一直在试图扩展、完善并发任务管理，从基础的thread支持，到future、promise、async、并行算法，到C++20的协程，都在逐步完善C++标准库的并发任务支持。

C++11提供的thread解决了基于线程的并发任务的基础设置，通过atomic解决了细粒度的原子操作问题，通过mutex和信号量解决了线程同步问题，通过promise、future和async解决了并发任务的创建与基本调度问题。

但直到C++20为止，我们依然需要关注很多并发任务执行的细节问题，无法通过标准库解决并发任务的高层调度问题。比如后面这些问题。

• 如何控制同时执行的并发任务数量。
• 如何解决任务的错误重试机制。
• 如何处理多个异步任务之间的串行、并行甚至条件调度。
• 如何更方便地在两个并发任务中发送接收消息等等。

C++ Executors的目标就是解决这些问题，我们这就来说说executors中的概念与提供的能力。

第一个概念就是executor。

executor本质是一个concept，表示可以被execute和schedule等调度函数调用的类型，它可以是一个函数、仿函数，也可以是一个Lambda函数。

对于其他调度函数，它们通过调用executor来提交并发任务。假如说，我们需要通过线程池来执行任务，那么可以创建一个线程池对象，并从线程池对象中获取一个executor。

#include <string>
#include <iostream>
#include <execution>
 
int main() {
    using namespace std::execution;
    
    std::static_thread_pool pool(4);
    executor auto poolExecutor = pool.executor();
 
    execute(poolExecutor, [] { std::cout << "这是一个在线程池中执行的任务"; });
 
    return 0;
}

在代码第8行，定义了一个大小为4的线程池。接着，通过executor成员函数获取了一个可以在线程池中执行并发任务的executor。然后，调用execute函数，execute会调用poolExecutor将这个Lamba函数提交到线程池中执行。

这种情况下，executor帮我们屏蔽了提交并发任务的所有细节，为其他的任务调度函数提供通用的调度接口。当然executor只是一个抽象，所以底层实现并不一定是线程——我们同样可以将coroutine包装成executor，因此executor是一个通用的并发任务接口。

第二个重要的概念是sender/receiver。

虽然标准定义了通用的executor。但是，用于调用executor执行任务的execute函数，它的返回类型为void。因此，我们无法通过链式调用的形式将多个并发任务串联在一起执行，就更不用说完成一些更高级的并发任务连接了。

为此，标准提出了sender和receiver。sender是一个创建之后不会自动执行的调度任务，需要等到在它后面连接一个receiver之后，才会开始执行。当sender执行完成后，就会调用receiver约定的接口将数据传递给receiver，并开始执行receiver，标准中将receiver连接到sender后的函数就是connect，伪代码如下所示。

#include <string>
#include <iostream>
#include <execution>
 
int main() {
    sender auto snd = create_sender();
    receiver auto rec = create_receiver();
    std::execution::connect(snd, src);
 
    return 0;
}

那我们要如何实现链式调用呢？这时就需要引入通用异步算法这个概念了。

所谓通用异步算法，就是一个接收用户自定义任务作为sender的函数，该函数会调用connect将该sender与算法内部的一个receiver连接，然后包装成一个新的sender返回给调用方，这样调用方就可以将这个sender传给下一个通用算法或者connect其他的计算任务，最终形成链式调用。标准库中future/promise的then就是通过这种方式实现的。

最后一个重要的概念是scheduler。

我们可能经常会碰到一种情况，就是有多个并发任务，使用相同的sender。如果直接链接sender对象和多个任务。很有可能会产生竞争问题。

为此，C++标准提出了scheduler。它主要通过schedule函数返回，该函数会返回一个新的sender作为内部sender的工厂，这样即使将同一个scheduler连接到多个receiver，也不会引发数据竞争问题。

网络库

接下来，我为你介绍一个“有些可能”推出的标准网络库——networking。我为什么说“有些可能”呢？这是因为标准网络库已经在标准中，被推迟了无数次