克莉丝随笔

通过 Matrix-WeChat 将微信消息转发至 Beeper

Tue, 26 Nov 2024 00:00:00 +0000

平时不怎么用微信，原因是微信会导致我给 PowerToys 配置的快捷键映射全部失效，具体参考这个 PowerToys Issue。

总之，虽然 Issue 里已经解决了这个问题，但是长期的习惯下来，我也不怎么在 Windows 上挂微信了。根本原因还是我微信上朋友很少。

不过最近因为特殊原因被迫 24 小时挂微信，得知有通过 matrix-wechat 将微信消息转发到 Matrix 的方法，因此尝试了一下。按照项目作者写的一个简单的教程，可以使用他的 docker image 快速 docker-compose up 一系列服务。

不过因为本人懒+穷，不原因自建一个 matrix homeserver，于是采用群友建议的 Beeper 服务器方案，成功将微信消息转发至 Beeper.com 上，也可以使用任意 Matrix 客户端接受消息。

概念

Matrix 是一个公开的分布式加密通信协议。只要是实现了 Matrix 协议的服务器，都可以使用 Matrix 协议互相通信。通过这个协议，在 A Matrix 服务器上注册的用户同样可以和 B Matrix 服务器上注册的用户互相发送消息、处于同一个群组。

最常见的 Matrix 服务器是 matrix.org，当然本文会用到 Beeper 的服务器 beeper.com。同时由于 matrix 协议是公开的，任何人都可以自建自己的服务器，因此有无数的 Homeserver 的存在。

我们一般通过 Matrix 客户端去 Matrix 服务器获取信息展示出来，一个比较知名的 Matrix 客户端包括 Element.io，可以直接用网页端登录。

那么逻辑就比较清晰了，我们是希望有一个自建的 Homeserver，为每一个微信好友创建一个虚拟 Matrix 账号，然后将微信消息转发到这个 Homeserver 上。这样的话，就可以用任意的 Matrix 客户端读取，而不必须在每个手机电脑上登录微信了。只是为了在外地也能读到某个 Homeserver 上的信息，这个 Homeserver 就必须要可以公网访问，这样 Matrix 客户端才能访问到。

这里的 Beeper 就起到了这个 Homeserver 的作用。因为 Beeper 为每个账号提供了一个 Hungry Server，因此不需要用户自己提供公网 IP、不需要用户自己提供域名，本地有一台电脑连上 Beeper 就可以跑 Bridge。

Matrix-WeChat 是 Bridge，它的作用是桥接本地应用 WeChat 和 Matrix 服务器。Bridge 也被称作 AppService。

准备

需要在 beeper.com 下载 Beeper 客户端后注册一个账号，注册非常简单，只需要提供邮箱和一个唯一 ID 也就是用户名。不需要记忆密码，免费，不要有心理负担。

后文假设你注册的用户名是 xr1s，由于 Beeper 原生支持 Matrix 协议，因此你直接获得了一个 Matrix 账号 @xr1s:beeper.com，可以在任何 Matrix 客户端登录。顺便欢迎来 Coder OT 玩玩。

下载 Beeper 官方的 Bridge Manager bbctl，它的作用是连接 Matrix Bridge 和 Beeper 服务器。

然后还需要下载 matrix-wechat 和 matrix-wechat-agent 源代码。重点注意 Agent 不要下 Release 了，因为他 Agent Release 版本有 Bug，修复后没有发新版，除此之外，启动方式和文档中所写的不一样，它不会读配置文件，所有参数都需要命令行传递。Matrix-WeChat Release 可能没有问题，但是同一个作者，保险起见还是自己编译吧。对，我们需要编译，所以需要基础的 Go 开发环境，不过 Go 编译很简单。

将 matrix-wechat 编译成 Linux ELF，matrix-wechat-agent 编译成 Windows EXE。

`1`	`GOOS=windows GOARCH=amd64 go build .`

就可以交叉编译了，还是很简单的。

matrix-wechat-agent.exe 还需要几个 dll 来支持运行，去 ljc545w/ComWeChatRobot 下载 Release，目前的最新版本是 3.7.0.30-0.1.1-pre，其中 3.7.0.30 是作者反编译的微信版本，因此使用的协议也是该版本微信的协议。Release 是一个 zip，我们只需要其中的 http/wxDriver.dll、http/wxDriver64.dll 和 http/SWeChatRobot.dll 这三个文件。

最后，我们仍然需要下载 ComWeChatRobot 对应的微信版本并安装到 Windows 或者 Wine 中。可以在微信官网找历史版本。或者使用微信官网的 Web Archive下载 3.7.0.30 版本的微信。

确认一下目前有这几个二进制可执行文件和动态加载库：

bbctl
matrix-wechat
matrix-wechat-agent.exe
wxDriver.dll
wxDriver64.dll
SWeChatRobot.dll

其中 bbctl 和 matrix-wechat 在 Linux 中运行，matrix-wechat-agent.exe 在 Windows 或者 Wine 中运行。

配置

bbctl

首先使用 bbctl 登录刚注册的 Beeper 账号，很简单：

`1`	`./bbctl login`

然后输入 Beeper 发送到你邮箱中的验证码即可。

首先需要在 Beeper 服务器上注册一个 bridge，使用 register 子命令，后面跟着 appservice 名称。

前缀 sh- 是必要的，用于 Beeper 识别为自建 Self-Hosting Bridge，后面的名字就是 bot 名，自己随便取就行，不会有冲突（每个 Beeper 账号下独立，同账号下不能有同名 bridge，不同账号 bridge 同名无所谓）。

`1`	`./bbctl register sh-wx`

Beeper 会返回给你一个 Registration 文件，是给 bbctl 使用的，先保存下来，随便放到一个文件里都可以，比如 registration.yaml 就行，可以不放到 bbctl 同一个目录下，命令行传参指定配置文件。不过为了方便管理，也不是不行。

id: 00000000-0000-0000-0000-000000000000
url: http://localhost:17778
as_token: hua_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX_XXXXXX
hs_token: huh_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX_XXXXXX
sender_localpart: sh-wxbot
rate_limited: false
namespaces:
    users:
        - regex: '@sh-wx_.+:beeper\.local'
          exclusive: true

其中 id、as_token、hs_token 都是用来和 Beeper 服务器验证身份的。后续也同样需要填入到 Bridge 配置文件中。

url 是本地 Matrix Bridge 监听的地址，需要和 Matrix Bridge 配置文件中的 appservice.hostname 与 appservice.port 一致。到文章目前还没生成，但是可以先填写默认值 http://localhost:17778，后续可以根据自己需要同时修改两处。

sender_localpart 是 Bridge 在 Beeper 服务器上的 Bot 名称，在 Bridge 配置文件中要保持一致。

namespaces.users 是 Bridge 在 Beeper 上能使用的用户名，Bridge 生成的用户 MXID 需要匹配这个正则，可以在 Bridge 配置文件中配置。

Matrix WeChat

在 matrix-wechat 所在目录直接执行下面的代码，生成一个 config.yaml 模板，需要注意的是这里配置文件必须要和二进制在同目录了：

1
2

touch config.yaml
./matrix-wechat

因为 config.yaml 是空，所以程序会报错退出。但是没关系，我们主要是用到 matrix-wechat 往 config.yaml 写入的默认配置（如果本来不存在这个文件，它是不会创建的，所以需要手动创建一个）。

下面是几个需要注意修改的字段，其它没有提及的字段不用动就好：

homeserver:
    address: https://matrix.beeper.com/_hungryserv/xr1s
    domain: beeper.local
    software: hungry
appservice:
    database:
        type: sqlite3-fk-wal
        uri: "file:matrix-wechat.data?_txlock=immediate"
    id: "00000000-0000-0000-0000-000000000000"
    bot:
        username: sh-wxbot
    as_token: "hua_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX_XXXXXX"
    hs_token: "huh_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX_XXXXXX"
bridge:
    hs_proxy: ""
    username_template: sh-wx_{{.}}
    permissions:
        "@xr1s:beeper.com": admin
    encryption:
        allow: true
        default: true
        appservice: true

homeserver.address 的值和 bridge.permissions 的用户名可以通过调用 ./bbctl whoami 获得。

appservice.database 可以先用 SQLite 快速把 Bridge 先跑起来，后续再自行配置 PostgreSQL。SQLite 也能跑，就是性能低，这篇文章就不讲解 PostgreSQL 相关知识了。

appservice.address 和 appservice.hostname、appservice.port 是 Bridge 本地监听地址，这三个值要保持一致，同时修改。如果要修改的话，同样需要同步在 bbctl 的 Registration 文件中修改。

appservice.id、appservice.as_token、appservice.hs_token 都是 Beeper 分配给你的 ID 和密钥，都在 ./bbctl register 中可以看，也就是上面的 Registration 文件，保存好就行。

appserivce.bot.username 要和 bbctl 中 register 的 sender_localpart 相匹配，是你的管理 Bot 名称，一切配置完成后在 Matrix 客户端私聊 Bot 就可以发指令控制了。

bridge.hs_proxy 不是什么重要的东西，只是为了去掉一句报错才加的这一行，没有也可以跑。

bridge.username_template 是 appservice 注册的用户 MXID 模板，需要注意要和 registration.yaml 中 namespaces 匹配，namespaces 是 Beeper 服务器为 AppService 预留的用户名格式，如果不符合格式的话，会出现为微信好友注册 Matrix 账号失败的情况。

bridge.permisions 是配置哪个用户对该 Bridge Bot 拥有什么样的权限，一般来说只要给自己配置 admin 就行了。

bridge.encryption 主要是桥到端加密信息的配置，是为了避免主服务器（也就是 Beeper）能读到我们微信聊天的明文。

另外注意 bridge.listen_address 和 bridge.secret 这两个字段，是自定义配置的 IP 端口和密钥，是留给 matrix-wechat-agent.exe 通信的。目前可以暂时先保留默认值 0.0.0.0:20002、foobar 不改动。

Matrix WeChat Agent

配置文件直接用仓库里 example 稍微改改就行，同样需要放到可执行文件同目录下 configuration.yaml。

wechat:
  version: 3.7.0.30
  listen_port: 22222
  init_timeout: 10s
  request_timeout: 30s

service:
  addr: ws://localhost:20002
  secret: foobar
  ping_interval: 30s

log:
  level: info

建议是改一改 service.addr 和 service.secret，当然 matrix-wechat 的配置文件中对应字段也需要同步修改。

启动

1
2

./bbctl proxy -r registration.yaml
./matrix-wechat

`1`	.\matrix-wechat-agent.exe`

Agent 会启动一个 WeChat 实例，可以把它扔到 Wine 里眼不见心不烦。

需要注意 Agent 必须要自己编译了，不然会报奇怪的错误：

Error in appservice websocket: json: cannot unmarshal number into Go struct field WebsocketMessage.type of type string
Error in appservice websocket: websocket: close 1006 (abnormal closure): unexpected EOF

Matrix 客户端初始化

服务启动完成后，随便找一个 Matrix 客户端登录 Beeper 账号 @xr1s:beeper.com（当然，你可以直接用 Beeper 自己的客户端，但是我不喜欢）。

私聊 @sh-wxbot:beeper.local。注意这里的 sh-wxbot 来自 bbctl 注册 bridge 时候使用的名称，储存在 Registration 文件的 sender_localpart 字段。beeper.local 是固定的，Beeper 服务器会为每个用户隔离出独立的 beeper.local，也就是说每个用户访问 beeper.local 的时候，Beeper 服务端都会使用用户名去找该用户注册的 Bridge。

如果启动成功一切顺利的话，这时候是能直接搜到这个 Bot 的，去发一条消息，比如 help，有回应就成功一半了。然后发送 login，会发送一张二维码让你登录微信。登录成功后最好分别使用私人（文件传输助手就行）和群聊发送消息测试一下。应该来说是没啥问题的。

收尾

需要注意的是如果 matix-wechat 或者 matrix-wechat-agent 退出，那后续重启就需要重新扫码登录了。似乎是微信的限制，所以目前最好是保持常开。

如果需要删除 Beeper 上的服务器，使用 ./bbctl delete sh-wx 即可。记得把本地的 SQLite 数据文件或者 PostgreSQL 数据表清空，否则下次注册可能会遇到服务器上仍未创建的私聊或者群聊，matrix-bridge 读数据库发现存在，就不为你创建新的账号或房间，直接收发消息导致报错的问题。

然后可以 Docker 化这些配置，我还是懒，反正逻辑就是上面这样，Docker 搞起来也不麻烦。

莫比乌斯反演

Tue, 03 Oct 2023 00:00:00 +0000

其实就是重新整理了一下 Introductory Combinatorics Fifth Edition 容斥原理一章莫比乌斯反演一节，修正了书上错误的内容，加上了一些证明的内容。虽然我想说的和网上已有的资料大同小异——容斥原理、二项式反演和数论反演——不过本文打算从最一般、定义在偏序集上的 Möbius 反演开始。

本文可能过于理论化，刷题记录会扔在另一篇文章中，到时候会介绍莫比乌斯反演是如何为计算提供帮助和优化的，可能这样才更适合算法竞赛中的反演入门。

莫比乌斯反演是这么个东西，当我们有定义在偏序集 $\mathcal F(S,\le)$ 上的函数 $f$，和 $\displaystyle F(x,y)=\sum_{x\le z\le y}f(x,z)$，可以通过莫比乌斯反演求得 $\displaystyle f(x,y)=\sum_{x\le z\le y}F(x,z)\mu(z,y)$，其中 $\mu$ 是 $\mathcal F(S,\le)$ 上的莫比乌斯函数。更一般的形式中，当 $x=0$ 时候，可以简写成 $\displaystyle F(y)=\sum_{z\le y}f(z)\implies f(y)=\sum_{z\le y}F(z)\mu(y,z)$。

本质上，容斥原理、二项式反演、数论反演都是莫比乌斯反演在特定偏序集上的不同实例。

前置知识

偏序关系

偏序是一种二元关系，较为常见的偏序关系有实数域 $\mathbb R$ 上的 $\le$ 关系、集合之间的子集 $\subseteq$ 还有整数之间的整除 $|$ 关系等。

更抽象地，偏序被定义为一个集合和一个关系的二元组，如实数上的 $\le$ 关系即为形如 $(\mathbb R,\le)$ 的二元组。

对于偏序关系 $(S,\le)$，需要满足性质：

自反性： $\forall a\in S:a\le a$
传递性： $\forall a,b,c\in S:(a\le b\land b\le c)\implies a\le c$
反对称性： $\forall a,b\in S:(a\le b\land b\le a)\implies a=b$

反对称性中的 $=$ 就表示 $a$ 和 $b$ 是同一个元素，其实就是说明没有两个不同的元素同时 $\le$ 对方，它们要么有确定顺序的 $\le$ 关系，要么没有关系。

为了方便阐述，在偏序 $\le$ 的基础上定义关系，\begin{equation*} \begin{align*} & a\ge b: && b\le a \\ & a\lt b: && (a\le b)\land(a\neq b) \\ & a\gt b: && b\lt a \end{align*} \end{equation*}

需要注意 $\not\le$ 和 $\gt$ 的区别，$\not\le$ 可以是不构成关系，而 $\gt$ 是有关系的，也就是 $\gt$ 组成的关系集是 $\not\le$ 的子集。$\ge$ 和 $\not\lt$ 类似。

卷积

下文中只考虑定义在偏序集 $(D,\le)$ 上，定义域为 $D\times D$ 的实值函数集合 $\mathcal F(D,\le)$——实值函数 $f$ 就是说值域是实数域 $f:D\times D\to\mathbb R$——且该集合满足其中的所有函数 $f\in\mathcal F(D,\le)$ 对于所有定义域中的元素 $\forall x,y\in D: x\not\le y$ 有 $f(x,y)=0$ 且 $\forall x,y\in D:x=y\implies f(x,y)\neq 0$。

设函数 $f,g\in\mathcal F(D,\le)$，定义卷积 $*$ 为

\begin{equation*} \end{equation*}

\begin{equation*} (f*g)(x,y)=\left\{ \begin{align*} & \sum_{x\le k\le y}f(x,k)g(k,y) && \text{for }x\le y \\ & 0 && \text{otherwise} \\ \end{align*} \right. \end{equation*}

显然有结合律 $(f*g)*h=f*(g*h)$，但无交换律。

事实上，若 $D$ 可数且 $(D,\le)$ 满足全序关系的话，将函数 $f\in\mathcal F(D,\le)$ 定义域中的元素按行纵依序排列，以对应的函数值填充矩阵，这实际上就是一个上三角矩阵，函数卷积即为矩阵乘法，这也从另一方面说明了没有交换律。

Iverson 括号

定义 Iverson 括号

\begin{equation*} [cond]=\left\{\begin{align*} & 1 && \text{if }cond\text{ is true} \\ & 0 && \text{otherwise} \\ \end{align*}\right. \end{equation*}

Kronecker delta 函数

定义 Kronecker delta 函数 $\delta(x,y)=[x=y]$。

和积分中的克罗内克函数类似，此处定义的克罗内克函数满足对于任意 $f\in\mathcal F(D,\le):\delta*f=f*\delta=f$。

实际上，delta 函数即为群 $(\mathcal F(D,\le),*)$ 中的单位元。在可数全序集上这是一个单位矩阵。

Zeta 函数

定义 Zeta 函数 $\zeta(x,y)=[x\le y]$。

这里的 Zeta 函数其实就是偏序集的一种表示。在可数全序集上这是一个全 1 的上三角矩阵。

Möbius mu 函数

定义

对于所有 $f\in\mathcal F(D,\le)$，构造 $f^{-1}$ 为

\begin{equation*} f^{-1}(x,y)=\left\{\begin{align*} &-\dfrac1{f(y,y)}\sum_{x\le k\lt y}f^{-1}(x,k)f(k,y) & \text{for }x\lt y\\ &\dfrac1{f(y,y)}&\text{for }x=y\\ &0&\text{for }x\not\le y \end{align*}\right. \end{equation*}

需要注意，虽然 $f^{-1}(x,y)\text{ for }x\lt y$ 的定义依赖到了$f^{-1}(x,z)\text{ for }x\le z\lt y$，但是不存在反向的依赖，因此可递归定义。

可以证明 $f^{-1}*f=\delta$，如下：

\begin{equation*} \begin{align*} (f^{-1}*f)(x,y)=&\sum_{x\le k\le y}f^{-1}(x,k)f(k,y) \\ =&f^{-1}(x,y)f(y,y)+\sum_{x\le k\lt y}f^{-1}(x,k)f(k,y) \\ \end{align*} \end{equation*}

当 $x=y$ 的情况上式显而易见可得值为 $1+0=1$。当 $x\neq y$ 时，再将 $f^{-1}(x,y)$ 定义带入展开有：

\begin{equation*} \begin{align*} & f^{-1}(x,y)f(y,y)+\sum_{x\le k\lt y}f^{-1}(x,k)f(k,y) \\ = & \left[-\dfrac1{f(y,y)}\sum_{x\le k\lt y}f^{-1}(x,k)f(k,y)\right]f(y,y)+\sum_{x\le k\lt y}f^{-1}(x,k)f(k,y) \\ = & -\sum_{x\le k\lt y}f^{-1}(x,k)f(k,y)+\sum_{x\le k\lt y}f^{-1}(x,k)f(k,y) \\ = & 0 \\ \end{align*} \end{equation*}

同理可证明 $f*f^{-1}=\delta$，这里就能证明 $\delta$ 是群 $(\mathcal F(D,\le),*)$ 的单位元了。最后，我们在此定义 Möbius 函数 $\mu=\zeta^{-1}$。

性质

根据卷积定义，$\displaystyle\sum_{x\le z\le y}\mu(x,z)\zeta(z,y)=\delta(x,y)$，根据 $\zeta$ 定义我们有 $\displaystyle\sum_{x\le z\le y}\mu(x,z)=\delta(x,y)$，通过将 $\mu(x,y)$ 移出累加符号，这等价于

\begin{equation*} \mu(x,y)=\left\{\begin{align*} & -\sum\limits_{x\le z\lt y}\mu(x,z) && \text{for }x\lt y \\ & 1 && \text{for }x=y \\ & 0 && \text{for }x\not\le y \end{align*}\right. \end{equation*}

$(\mathbb N,\le)$

\begin{equation*} \mu(x,y)=\left\{\begin{align*} & 1 && \text{for }x=y \\ &-1 && \text{for }x+1=y \\ & 0 && \text{otherwise} \\ \end{align*}\right. \end{equation*}

结论是很显然的，递推一下就得到了。

事实上这个结论对于所有可数的全序集而言均正确。

$(\mathcal P(S),\subseteq)$

集合的幂集上的包含关系，其 Möbius 函数为：

\begin{equation*} \mu(X,Y)=\left\{\begin{align*} & (-1)^{|Y|-|X|} && \text{for } X\subseteq Y \\ & 0 && \text{otherwise} \\ \end{align*}\right. \end{equation*}

归纳证明：

\begin{equation*} \begin{align*} \mu(X,Y) & =-\sum_{X\subseteq Z\subset Y}\mu(X,Z) \\ & =-\sum_{X\subseteq Z\subset Y}(-1)^{|Z|-|X|} \\ & =-\sum_{\varnothing\subseteq Z\subset Y\setminus X}(-1)^{|Z|} \\ & =-\sum_{k=0}^{|Y|-|X|-1}\binom {|Y|-|X|}k(-1)^k \\ & =(-1)^{|Y|-|X|}-\sum_{k=0}^{|Y|-|X|}\binom{|Y|-|X|}k(-1)^k \\ & =(-1)^{|Y|-|X|}-(1-1)^{|Y|-|X|} && \triangleright\text{ 二项式定理} \\ & =(-1)^{|Y|-|X|} \end{align*} \end{equation*}

偏序集直积

设两个偏序集 $(S,\le_S)$ 和 $(T,\le_T)$，直积 $(S,\le_S)\times(T,\le_T)=(S\times T,\le)$，这里要求 $\le$ 满足 $\forall (s,t),(s’,t’)\in X\times Y:(s,t)\le(s’,t’)\iff(s\le_Ss’)\land(t\le_Tt’)$。

设 $(S,\le_S)$ 的 Möbius 函数为 $\mu_S$，$(T,\le_T)$ 的 Möbius 函数为 $\mu_T$，其直积的 Möbius 函数为 $\mu$，则有：

\[\forall s,s’\in S,t,t’\in T:\mu((s,t),(s’,t’))=\mu_S(s,s’)\mu_T(t,t’)\]

还是归纳法证明：

\begin{equation*} \begin{aligned} \mu((s,t),(s’,t’))= & -\sum_{(s,t)\le(s’’,t’’)\lt(s’,t’)}\mu((s,t),(s’’,t’’)) \\ = & -\sum_{(s,t)\le(s’’,t’’)\lt(s’,t’)}\mu_S(s,s’’)\mu_T(t,t’’) \\ = & \mu_S(s,s’)\mu_T(t,t’)-\sum_{s\le_{\scriptstyle S}s’’\le_{\scriptstyle S}s’}\mu_S(s,s’’)\sum_{t\le_{\scriptstyle T}t’’\le_{\scriptstyle T}t’}\mu_T(t,t’’) && \triangleright 提取 (s’’,t’’)=(s’,t’) 一项 \\ = & \mu_S(s,s’)\mu_T(t,t’) && \triangleright\sum_{i\le k\le j}\mu(i,k)=\delta(i,j) \end{aligned} \end{equation*}

这个结论将会在接下来的求解自然数关于整除关系形成的偏序集上的 Möbius 函数用到。

$(\mathbb N,|)$

对于任意定义域中的 $x,y$，当 $x|y$，有 $\mu(x,y)=\mu\left(1,\dfrac yx\right)$。这个结论是很显然的，证明的话归纳即可，两侧参数相等时结论显然，不等时：

\begin{equation*} \begin{aligned} \mu(x,y) & =-\sum_{z|\frac yx\land z\neq\frac yx}\mu(x,xz) \\ & =-\sum_{z|\frac yx\land z\neq\frac yx}\mu(1,z) \\ & =\mu\left(1,\frac yx\right) \end{aligned} \end{equation*}

设 $\mathbb P_m$ 为 $m$ 的素因数集合，则有：

\begin{equation*} \mu(1,m)=\left\{\begin{align*} & 1 && \text{for }m=1 \\ & (-1)^{|\mathbb P_m|} && \text{for }m=\prod\limits_{p\in \mathbb P_m}p \\ & 0 && \text{otherwise} \end{align*}\right. \end{equation*}

证明：

设 $n$ 的唯一素因数分解为 $\displaystyle n=\prod_{k}p_k^{\alpha_k}$，$p_k$ 为 $n$ 的第 $k$ 个素因子，$\alpha_k$ 是 $p_k$ 对应的幂次。

对于任何可以整除 $n$ 的数字 $s=\prod\limits_{k}p_k^{\beta_k}, t=\prod\limits_{k}p_k^{\gamma_k}$ 来说，若 $s|t$，有 $\forall k:\beta_k\le\gamma_k$。所以 $n$ 的因子组成的偏序集可以认为是 $k$ 个 $\alpha_k+1$ 大小的偏序集的直积。

由于每个子偏序集都是只由 $p_k$ 的幂次组成，实际上这些都是全序集。前面已经证明了对于所有的全序集的 $\mu$ 函数情况，此处同理：

\begin{equation*} \mu(1,p_k^r)=\left\{\begin{align*} & 1 && \text{for }r=0 \\ & -1 && \text{for }r=1 \\ & 0 && \text{otherwise} \\ \end{align*}\right. \end{equation*}

于是利用 Möbius 直积公式可证明结论。

当我们只考虑 Möbius 函数的第一个参数为 1 并略去时，得到的形式即为数论中的 Möbius 函数，数论 Möbius 函数满足积性 $m\bot n\implies\mu(mn)=\mu(m)\mu(n)$。前几项的值如下图所示：

Möbius 反演

设对于 $F,G\in\mathcal F(D,\le)$ 两个函数满足： $\displaystyle G(x,y)=\sum_{x\le z\le y}F(x,z)$，则有 $\displaystyle F(x,y)=\sum_{x\le z\le y}G(x,z)\mu(z,y)$。

证明：

\begin{equation*} \begin{align*} \sum_{x\le z\le y}G(x,z)\mu(z,y)& =\sum_{x\le z\le y}\mu(z,y)\sum_{x\le w\le z}F(x,w) \\ & =\sum_{x\le z\le y}\mu(z,y)\sum_{w\in D}F(x,w)\zeta(w,z) \\ & =\sum_{w\in D}F(x,w)\sum_{w\le z\le y}\zeta(w,z)\mu(z,y) \\ & =\sum_{w\in D}F(x,w)\delta(w,y) \\ & =F(x,y) \end{align*} \end{equation*}

上面是一般的 Möbius 反演公式。在偏序集具有最小元（下面假设为 $0$）且函数下界取到最小元的时候，二元函数可以默认第一个参数为 $0$ 简写为一元函数，也就是 Introductory Combinatorics Fifth Edition 上的形式：

当 $F,G\in\mathcal F(D,\le)$ 满足 $G(0,x)=\sum\limits_{y\le x}F(0,y)$ 时，有 $F(0,x)=\sum\limits_{y\le x}G(0,y)\mu(y,x)$。

在数论中，存在最小元为 $1$，Möbius 反演可以化为另一种形式：

\[G(n)=\sum_{k|n}F(k)\iff F(n)=\sum_{k|n}\mu\left(\dfrac nk\right)G(k)\]

容斥原理

设有集合 $A_1,A_2,A_3,A_4,\cdots,A_n$，求 $\displaystyle\left|\bigcup_{k=1}^nA_k\right|$

利用容斥原理，我们知道这个的结果为 $\displaystyle\left|\bigcup_{k=1}^nA_k\right|=\sum_{\mathcal T\subseteq\{A_1,A_2,\ldots,A_n\}\land\mathcal T\neq\varnothing}(-1)^{|\mathcal T|-1}\left|\bigcap _{A\in\mathcal T}A\right|$

证明：

设集合族 $\mathcal A=\{A_1,A_2,A_3,A_4,\cdots,A_n\}$，全集 $\displaystyle U=\bigcup_{A\in\mathcal A}A$，$\mathcal S$ 为 $\mathcal A$ 的子集，构造函数

\begin{equation*} \begin{align*} F(\mathcal S)&=\left|\left(\bigcap_{A\in\mathcal S}A\right)\cap\left(\bigcap_{A\in\mathcal A\setminus\mathcal S}U\setminus A\right)\right| \\ G(\mathcal T)&=\left|\bigcup_{A\in\mathcal T}A\right| \\ \end{align*} \end{equation*}

这里，$\displaystyle\bigcap_{A\in\mathcal S}A$ 的意思是 $\mathcal S$ 中所有集合都有的元素；$\displaystyle\bigcap_{A\in\mathcal A\setminus\mathcal S}U\setminus A$ 是 $\mathcal S$ 以外的集合都没有的元素，我们取它们的并集。换句话说，函数 $F(\mathcal S)$ 的结果是所有 $\mathcal S$ 中集合的交减去不在 $\mathcal S$ 中的集合的并。因此 $F$ 等价于

\begin{equation*} \begin{align*} & F(\mathcal S)=\left|\left(\bigcap_{A\in\mathcal S}A\right)\setminus\left(\bigcup_{A\in\mathcal A\setminus\mathcal S}A\right)\right| \\ \end{align*} \end{equation*}

从元素的视角去理解函数 $F$ 更简单一些，对于一个元素，当且仅当所有包含它的集合都在 $\mathcal S$ 中，所有不包含它的集合都不在 $\mathcal S$ 中，这个元素才对 $F(\mathcal S)$ 有贡献。于是我们可以得出一个结论：对于所有 $\mathcal A$ 的子集 $\mathcal S$，函数 $F$ 右侧的 $\displaystyle \left(\bigcap_{A\in S}A\right)\setminus\left(\bigcup_{A\in\mathcal A\setminus\mathcal S}A\right)$，是对 $U$ 的一个划分。那么自然的，$\displaystyle\sum_{\mathcal S\subseteq\mathcal A}F(\mathcal S)=|U|$。

稍作拓展，可以得到一个结论： $\displaystyle G(\mathcal T)=\sum_{\mathcal S\supseteq\mathcal T}F(\mathcal S)$。这很好理解，当 $\mathcal S$ 中始终包含某些集合时，这些集合的元素总会出现在某个 $F(\mathcal S)$ 中，因为它是划分。

到这里已经明确了 $F$ 的性质，回过头来，这是一个关于 $\supseteq$ 的偏序集。我们已经得到 $\subseteq$ 偏序关系的 Möbius 函数，通过引入一个不加证明（很容易证明）的结论： $\mu_\le(a,b)=\mu_\ge(b,a)$，可以直接得到 $\supseteq$ 的 Möbius 函数。

运用 Möbius 反演可以得到： $\displaystyle F(\mathcal S)=\sum_{\mathcal A\supseteq\mathcal T\supseteq\mathcal S}\mu(\mathcal T,\mathcal S)G(\mathcal T)=\sum_{\mathcal A\supseteq\mathcal T\supseteq\mathcal S}(-1)^{|\mathcal T|-|\mathcal S|}G(\mathcal T)$

接下来取 $\mathcal S=\varnothing$，有 $\displaystyle F(\varnothing)=\left|U\setminus\left(\bigcup_{A\in\mathcal A}A\right)\right|$

回代得到结论： $\displaystyle\left|U\setminus\left(\bigcup_{A\in\mathcal A}A\right)\right|=\sum_{\mathcal A\supseteq\mathcal T}(-1)^{|\mathcal T|}\left|\bigcap_{A\in\mathcal T}A\right|$

当把全集 $U$ 的影响去掉之后，就得到本段开始所写的容斥原理公式。

二项式反演

二项式反演的公式是 $\displaystyle g(x)=\sum_{y=0}^x(-1)^y\binom xyf(y)\iff f(x)=\sum_{y=0}^x(-1)^y\binom xyg(y)$

上面从 Möbius 反演出发证明了容斥原理，本节试图从容斥原理构造特殊的集族证明二项式反演。

构造 $n$ 个集合，使得 $\forall k\in\{1,2,3,4,\cdots,n\}$ 满足任选 $k$ 个集合的交均为固定值，设为 $g(k)$。这样的集族挺好构造，但是有一些特殊情况，比如这个公式对于负数也是成立的（而且大部分你构造不出来的情况，就是 $g$ 或者 $f$ 里存在负数），但是没法用这个证明，这里就……懒得管了。

有

\begin{equation*} \begin{align*} g(k)&=|A_1\cap A_2\cap A_3\cap A_4\cap\cdots\cap A_k| \\ &=\left|\overline{\overline{A_1}\cup\overline{A_2}\cup\overline{A_3}\cup\overline{A_4}\cup\cdots\cup\overline{A_k}}\right| \end{align*} \end{equation*}

设

\begin{equation*} \begin{align*}f(k) &=\left|\overline{A_1}\cap\overline{A_2}\cap\overline{A_3}\cap\overline{A_4}\cap\cdots\cap\overline{A_k}\right| \\ &=\left|\overline{A_1\cup A_2\cup A_3\cup A_4\cup\cdots\cup A_k}\right| \end{align*} \end{equation*}

应用容斥原理，直接可得 $\displaystyle g(x)=\sum_{y=0}^x(-1)^y\binom xyf(y)$，$\displaystyle f(x)=\sum_{y=0}^x(-1)^y\binom xyg(y)$

当然我们也可以从定义出发证明二项式反演，和证明 Möbius 反演的过程类似，只需要证明 $\displaystyle{\sum_{k=m}^n(-1)^{k-m}\binom nk\binom km=\delta(n,m)}$ 即可。事实上，只要满足 $\displaystyle{\sum_{k=m}^n(-1)^{k-m}A(n,k)B(k,m)=\delta(n,m)}$ 形式的数列 $A,B$ 均有可反演的性质。

除了二项式系数自成一对外，还有 $\displaystyle\sum_{k=m}^n(-1)^{k-m}\genfrac[]{0pt}0nk\genfrac\{\}{0pt}0km=\delta(m,n)$、$\displaystyle\sum_{k=m}^n(-1)^{k-m}\genfrac\{\}{0pt}0nk\genfrac[]{0pt}0km=\delta(m,n)$ 和 $\displaystyle\sum_{k=m}^n(-1)^{k-m}\genfrac\lfloor\rfloor{0pt}0nk\genfrac\lfloor\rfloor{0pt}0km=\delta(m,n)$。上面的式子中，$\genfrac[]{0pt}0{}{}$ 表示第一类 Stirling 数，$\genfrac\{\}{0pt}0{}{}$ 表示第二类 Stirling 数，$\genfrac\lfloor\rfloor{0pt}0{}{}$ 表示 Lah 数。

数论反演

其实就是定义在 $(\mathbb N,|)$ 偏序集上的函数的 Möbius 反演。

对于数论函数 $f,g$，有 $\displaystyle g(n)=\sum_{d|n}f(d)\iff f(n)=\sum_{d|n}\mu(d,n)g(d)$

因为前面证明过 $\mu(a,b)=\mu\left(1,\dfrac ba\right)$ 而且默认情况下会把 $\mu(1,m)$ 表示成 $\mu(m)$，上式就可以化为网上常见的一般的形式，也就是 Dirichlet 卷积形式。

C++ 用户定义 Ranges 算子

Sun, 13 Aug 2023 00:00:00 +0000

写这篇文章只是我在奇怪为什么没人介绍怎么自定义 C++ Ranges 标准库的 View Adaptor。虽然说 C++20 标准其实还没定义要怎么实现，但是不至于连 range-v3 的都没有吧？

C++20 新引入的 Range 的必要性无需赘述，它解耦了迭代和计算的逻辑，抽象出「范围」的概念，使得相比于旧的 Algorithm 库，Range 库中的算法更容易被组合，借此可以写出更清晰、运行效率更高的代码。作为 C++20 的四大件、C++23 的顶梁柱之一，基本上就是奔着取代前 C++20 的算法库来的。

文中的代码故意不一次性完整给出，是为了读者能自己理解并整理代码。如果需要完整代码的话可以直接看 GitHub Gists。

文章中涉及到少量 CRTP 的知识，可以前置阅读 C++ CRTP 简介。

概念

范围 Range

从定义上来讲，Range 就是有 begin 和 end 方法的类型。

另外有 end 方法并不意味着 Range 必须是个有限的区间，事实上它可以是无限的。比如 std::ranges::views::repeat()。

当然还有很多特殊情况，比如 C 风格的数组，尽管没有方法，它也被特别提及并定义为一个 Range；比如虽然有着 begin 和 end 方法，但是返回的类型并不满足迭代器 concept input_or_output_iterator 的类型，这又不是 Range。过于细节的这里就不作阐述了，能理解就行。

template <class T>
concept range = requires(T &t) {
  std::ranges::begin(t);
  std::ranges::end(t);
};

从概念上来讲，Range 表达的是我们将要处理的一个数据序列。它不一定是连续的，不仅可能像 std::forward_list 一样在内存中不连续，它甚至可能是在 std::vector 选中的几个满足特定条件的一些元素，比如数组中所有的偶数数字这种非连续的序列。

视图 View

首先，View 是 Range，这意味着它有所有 Range 要求的属性，比如 begin 方法、end 方法、可迭代等等。

View 是视图，视图和容器的区别在于它不持有数据，它只是数据的一种展现方式，因此它的复制是 $O(1)$ 的。这里的定义涉及到所有权的概念，但是因为这个概念在其它语言、应用场景（比如数据库视图）下也是互通的，所以不再展开。如果你理解 C++17 的 std::string_view，那你应该也能理解这里的 View。

C++ 的定义中，它要求 T 的视图 std::ranges::view<T> 是关于 T 的范围 std::ranges::range<T>、是继承自 std::ranges::view_base 或仅继承自 std::ranges::view_interface<T> 的，且 T 是可移动的 std::movable<T>。

也就是

template <class T>
concept view =
    std::ranges::range<T> && std::movable<T> && std::ranges::enable_view<T>;

template <class T>
concept std::ranges::enable_view<T> =
    std::derived_from<T, view_base> || __is_derived_from_view_interface<T>;

范围适配器 Range Adaptor

需要注意 Range Adaptor 和 Range 的区别。Range 终究可以被迭代，这意味着它代表着的是数据；而 Range Adaptor 代表的是计算，或者说操作。Range Adaptor 和 Range 的关系是，我们可以通过 Range Adaptor 在 Range (View) 之间进行转换。

举个例子，std::ranges::views::filter 是一种 Range Adaptor，std::ranges::transform 是另一种 Range Adaptor。

范围适配器闭包 Range Adaptor Closure

Range Adaptor Closure 是 Range Adaptor 未传入 Range 的调用结果。

举个比较实际的例子，下面的代码中，

container 是一个 std::vector<int> 容器，也是 Range；
std::ranges::views::filter 和 std::ranges::transform 分别是两种 Range Adaptor 对象；
filter([](int x) { return x % 2 != 0; }) 是 Range Adaptor Closure 对象；
transform([](int x) { return x * x * x; }) 也是 Range Adaptor Closure 对象；
container_view 是 View，并且 container 和 filter 的中间的计算结果也是另一个 View。

std::vector<int> container = {-27, 50, 51, 72, 89, 14, 8, -43, -20, 62};

auto container_view = container
  | std::ranges::views::filter([](int x) { return x % 2 != 0; })
  | std::ranges::views::transform([](int x) { return x * x * x; });

实现

实现起来其实并不复杂，除了 View 和迭代器的定义之外，说白了就是多给 Adaptor Closure 实现一个 operator| 的事情。

这里顺便说一个八卦，Google C++ 编程规范中提到：

Define overloaded operators only if their meaning is obvious, unsurprising, and consistent with the corresponding built-in operators. For example, use | as a bitwise- or logical-or, not as a shell-style pipe.

只有当重载运算符的含义显而易见、不足为奇并且与相应的内置运算符一致时，才定义重载运算符。例如，使用 | 作为位或逻辑或，而不是作为 shell 样式的管道。

不知道他们现在如何看待这个问题。

首先我们来实现一个 View，选一个 C++23 还没有的而且比较简单的来实现，比如 chain，含义是将两个 Range 前后串联起来。

从简单开始，为了避免复杂模板对代码的混淆影响到读者的理解，先只考虑实现一个只接受一对参数的 ChainView，也就是只接受 chain(view, another_view) 或 view | chain(another_view) 形式。

1
2
3

template <std::ranges::viewable_range LHS, std::ranges::viewable_range RHS>
class ChainView: public std::ranges::view_base {
};

std::ranges::view_base 其实是个空基类，它没有任何成员。这里继承的原因是标准要求所有 View 都要自此派生。

template <std::ranges::viewable_range LHS, std::ranges::viewable_range RHS>
class ChainView: public std::ranges::view_base {
private:
  LHS lhs;
  RHS rhs;
};

这里的 std::ranges::views::all_t 是无操作的 View Adaptor，它的作用在于避免复制，用于在 ChainView 中只保存数据的视图。

也就是说当输入的 Range 本身是持有数据的容器时， all_t 避免将容器复制到 ChainView 中，而只是保存容器的引用；而当 Range 已经是 View 的时候，它不会进行任何操作，因此也不会进行复制。

然后我们来实现 View 的核心逻辑——迭代器 Iterator，首先我们要保存底层迭代器类型方便后续处理。

template <std::ranges::viewable_range LHS, std::ranges::viewable_range RHS>
class ChainView: public std::ranges::view_base {
private:
  using LHSIterator = std::ranges::iterator_t<LHS>;
  using RHSIterator = std::ranges::iterator_t<RHS>;
  static_assert(
      std::same_as<
          typename std::iterator_traits<LHSIterator>::value_type,
          typename std::iterator_traits<RHSIterator>::value_type>,
      "简化起见, 迭代器返回的类型必须相同. 可以扩展成 std::common_type.");
  using ValueType = std::iterator_traits<LHSIterator>::value_type;

  class Iterator {
    // TODO
  };

  LHS lhs;
  RHS rhs;

public:
  ChainView() = default;

  ChainView(LHS lhs, RHS rhs): lhs{std::move(lhs)}, rhs{std::move(rhs)} {}
};

我们为 ChainView 实现模板实参推导，后面无论是通过 chain() 调用构造，还是用户手动构造的时候可以简化传参：

template <std::ranges::viewable_range LHS, std::ranges::viewable_range RHS>
ChainView(LHS &&, RHS &&) -> ChainView<
    std::ranges::views::all_t<LHS>,
    std::ranges::views::all_t<RHS>>;

接下来定义 Iterator，先简单搭好一些框架：

  class Iterator {
  private:
    ChainView *view = nullptr;
    std::variant<LHSIterator, RHSIterator> inner;

    friend class ChainView;

    // 构造器需要传入引用的 view
    // 因为在 ++iterator 跨越 LHS 和 RHS 的时候
    // 需要拿到 lhs.end() 和 rhs.begin()
    Iterator(ChainView *view, LHSIterator it)
        : view{view}, inner{std::move(it)} {}

    Iterator(ChainView *view, RHSIterator it)
        : view{view}, inner{std::move(it)} {}

  public:
    // concept std::ranges::input_range 需要这些定义
    // 满足 input_range 的 View 才能和标准库 Adaptor 互操作
    using difference_type = ptrdiff_t;
    using value_type = ValueType;

    // concept std::sentinel_for 需要实现默认构造函数
    // concept std::ranges::range 需要实现 sentinel_for
    Iterator() = default;
  };

  Iterator begin() { return Iterator{this, this->lhs.begin()}; }

  Iterator end() { return Iterator{this, this->rhs.end()}; }
};

然后来实现最重要的逻辑，operator++ 和 operator*：

template <std::ranges::viewable_range LHS, std::ranges::viewable_range RHS>
class ChainView: public std::ranges::view_base {
private:
  class Iterator {
  public:
    Iterator &operator++() {
      std::visit(
          [this]<typename T>(T &&iterator) {
            using Iterator = std::decay_t<T>;
            // iterator 到达 lhs.end() 时，需要转移到 rhs.begin()
            if constexpr (std::same_as<Iterator, LHSIterator>) {
              ++std::forward<T>(iterator);
              if (std::forward<T>(iterator) == this->view->lhs.end()) {
                this->inner = this->view->rhs.begin();
              }
            }
            // iterator 到达 rhs.end() 后不需要转移，可以被识别为结束
            if constexpr (std::same_as<Iterator, RHSIterator>) {
              this->inner = ++std::forward<T>(iterator);
            }
          },
          this->inner);
      return *this;
    }

    // concept std::input_or_output_iterator 需要后置自增
    Iterator operator++(int) {
      Iterator that = *this;
      ++*this;
      return that;
    }

    ValueType &operator*() const & {
      return std::visit(
          []<typename T>(T &&iterator) -> ValueType & {
            using Iterator = std::decay_t<T>;
            if constexpr (std::same_as<Iterator, LHSIterator>) {
              return *std::forward<T>(iterator);
            }
            if constexpr (std::same_as<Iterator, RHSIterator>) {
              return *std::forward<T>(iterator);
            }
            std::unreachable();
          },
          this->inner);
    }
};

到此为止，我们已经实现了最核心的逻辑接口，已经可以手动构造 ChainView 进行迭代了：

int main() {
  std::vector<int> vi = {0, 2, 4, 6, 8};
  std::deque<int> di = {1, 3, 5, 7, 9};

  ChainView cv{vi, di};
  for (const auto &i: cv) {
    std::println("{}", i);
  }
}

但是目前还没法使用 chain(vi, di) 或者 vi | chain(di) 形式调用，没那味儿。接下来我们实现一个 Adaptor。这个 Adaptor 应该可以接受双参数，这样才能用 chain(vi, di) 的形式直接构造 ChainView，这个 Adaptor 也要能接受单个参数，才能使用 vi | chain(di) 的形式调用。

我们先来实现双参数的，直接返回 ChainView 即可。

struct ChainAdaptor {
  template <std::ranges::viewable_range LHS, std::ranges::viewable_range RHS>
  auto operator()(LHS &&lhs, RHS &&rhs) const {
    return ChainView{std::forward<LHS>(lhs), std::forward<RHS>(rhs)};
  }
};

inline constexpr ChainAdaptor chain;

int main() {
  std::vector<int> vi = {0, 2, 4, 6, 8};
  std::deque<int> di = {1, 3, 5, 7, 9};

  for (const auto &i: chain(vi, di)) {
    std::println("{}", i);
  }
}

为了实现 vi | chain(di) 的调用形式，我们还需要实现一个 Closure 来暂存 di。

template <std::ranges::viewable_range View>
struct ChainAdaptorClosure {
private:
  View view;

public:
  explicit ChainAdaptorClosure(View view): view{std::move(view)} {}

  template <std::ranges::viewable_range LHS>
  friend auto operator|(LHS &&lhs, ChainAdaptorClosure<View> self) {
    return ChainView{std::forward<LHS>(lhs), self.view};
  }
};

template <std::ranges::viewable_range View>
ChainAdaptorClosure(View &&)
    -> ChainAdaptorClosure<std::ranges::views::all_t<View>>;

struct ChainAdaptor {
  template <std::ranges::viewable_range View>
  auto operator()(View &&view) const {
    return ChainAdaptorClosure{std::forward<View>(view)};
  }
};

int main() {
  std::vector<int> vi = {0, 2, 4, 6, 8};
  std::deque<int> di = {1, 3, 5, 7, 9};

  auto view = vi | chain(di)
      | std::ranges::views::filter([](int value) { return value % 3 != 0; })
      | std::ranges::views::transform(
                  [](int value) { return std::to_string(value); });
  std::ranges::for_each(view, [](auto value) { std::println("{}", value); });
}

最后一点，是 Closure 之间的组合，两个 Closure 之间可以执行 operator| 操作结合成全新的 Closure，然后整体传递给其它 Range 一起运算。这里我们还会需要一个 Closure 来暂存两个 Closure 运算的结果。但是我实在是懒得写了，可以自行意会一下，这个方法没有实现不影响 ChainView 的大部分使用场景。

到此为止，已经实现一个可以参与到标准库中的 Adaptor 了。

可能有人会想试一试能否参与到 range-v3 库的互相调用。理论上可以实现，但是上面的代码需要稍作改动，读者可以自行研究一下报错看看还缺了什么。

两个提示：

std::ranges::view_base 和 ranges::view_base 是两个不同的类型；
range-v3 要求用户自定义的 View 满足 ranges::default_constructible，但是 std::ranges::ref_view 并不是默认可构造的。

标准库帮助类

这里开始会有一些 CRTP 相关知识，再次提醒如果不知道 CRTP 的主要作用是用来给派生类生成方法，可以先阅读 C++ CRTP 简介。

实际上，如果用户要自己自定义 Range Adaptor，上面的代码有很多都可以重复利用，于是标准库也提供了一些帮助类，比如 std::ranges::view_interface 和 std::ranges::range_adaptor_closure 模板类。这两个类都是 CRTP 模板基类，需要派生类实现了某个方法才能继承。

std::ranges::view_interface 会根据用户定义 View 类型的 begin() 和 end() 方法，以及迭代器的类型生成常见的容器方法，比如 empty()、cbegin()、cend()、size()、front() 、back()，甚至 data() 等。

std::ranges::range_adaptor_closure 会根据用户 Closure 的 operator() 方法生成与 Range 运算的 operator| 方法和与另一个 Closure 运算的 operator| 方法，有效降低重复逻辑。

另外还有一处逻辑重复比较多的代码，就是通过 Adaptor 构造 Closure 的。很明显不论你是实现哪种 Range View Adaptor，他们 Adaptor 实现的重复度都极高，都是相似两种 operator()，一种直接返回 View 一种返回 Closure，而这个 Closure 也可以用一个通用类型实现。但是可惜标准库没有提供这种东西。这里可以参考 libstdc++ 的 std::ranges::views::__adaptor::_RangeAdaptor CRTP 模板基类，只需要实现 operator() 以及定义两个 static 常量，就可以直接生成 Adaptor 和复用 libstdc++ 的 Closure 类型，也就是 std::ranges::views::__adaptor::_Partial 类，可以大幅减少重复逻辑。就是可惜没有进标准库。

成品

其实说是成品还有瑕疵，因为还不支持 Closure 之间的计算。难度应该不大，等我有兴趣了再改。

不过如果一周内没加上那就有可能永远都不会加上了。

C++ Chain Range Adaptor.

在 macOS 上用 Game Porting Toolkit 运行原神崩铁

Sun, 23 Jul 2023 00:00:00 +0000

参考了在 Linux 上运行《原神》和《崩坏：星穹铁道》的方法，利用 macOS 14 的 Game Porting Toolkit 成功运行了 PC 版的《原神》和《崩坏：星穹铁道》。记录一下过程。

简单来说就是 Wine 没有自带 DirectX 的实现，以前都只能用第三方社区实现的 DXVK。而今苹果官方直接自己实现了一套 DirectX 接口给 Wine，叫做 D3DMetal，这样就能跑起来各种游戏了。所以这套东西的关键是苹果官网下载的 Game Porting Toolkit 中的 D3DMetal 二进制。

目前网上暂时没找到其它运行 PC 崩铁的方法。PlayCover 用过一段时间，太难用，不适合键鼠——不会有人上班带手柄吧？

出于对一些项目的保护目的，有些工具不方便直接提供，你可以直接从上下文中找到信息，但我不会直接写出来。没有解谜，能一眼看出来，主要是为了防止搜索引擎检索关键字直接搜到这篇文章。

⚠️绕过反作弊模块存在封号可能，风险自负⚠️

可以考虑使用小号免费游玩（Free Game BTW），避免财产损失。

虽然原神这么多年了没见过封号案例，崩铁则是从 1.2 开始之后没有听说过封号案例（这之前有群友被封过几天），我至今也还没有被封过号，不过还是谨慎为上。

本人的系统是 MBP 18，处理器 Apple M1 Pro，内存 32GB。游戏全特效的话，平时还能 60 帧，打个绽放基本上就只剩 45 帧了。这两个游戏双开的情况会很卡，不要学我，我只是为了截图演示。

准备

首先至少需要 M1 苹果芯片的 MacBook，操作系统需要升级到 macOS 14，目前正在 Beta 中。

macOS 13 的系统就算装了 Game Porting Toolkit 也会直接提示无法使用。

关于怎么开启 Beta 更新推送，可以参考苹果官网资料。

不建议普通用户升级测试版本。注意备份重要资料、注意提前准备降级回滚。

讲真，如果下面有一些略有些技术性的内容看不懂的话，真不建议升级 Beta 版本。

2024-02-15 更新：

macOS 14 Sonoma 现在已经正式了。但是原神 4.4 还是需要 14.4 Beta 版本。原因不明。

以上是基本要求。

特殊网络环境下可能需要代理等工具，请自备。

Game Porting Toolkit 安装

你需要下载 Command Line Tools，我亲自测试过 Beta、Beta 2、Beta 7 都可以正常编译 Game Porting Toolkit，而 Beta 3 和 Beta 4 都无法编译，网上也有数起编译失败的报告，没有测试过 Beta 5 和 Beta 6。同时你可以在这个页面提前搜索下载最新版的 Game Porting Toolkit，之后用得着。

2024-02-15 更新：

Command Line Tools 现在可以直接用正式版来编译安装了，15 和 15.1 都可以正常编译安装运行。

Game Porting Toolkit 可以用社区编译版，如果你不愿意自己编译的话，具体见下。

另外记得去官网下载原神和崩铁 PC 版本的安装包，安装 Game Porting Toolkit 非常耗时，可以提前下载一下安装包。你还可以找台 Windows 提前装好游戏本体，这样到需要的时候可以直接把 Windows 上的整个游戏目录复制到 macOS 中的对应位置就好，不需要再用启动器另外下载游戏了。这么做的好处是能并行安装 Game Porting Toolkit 和游戏本体，否则就需要先编译完 Game Porting Toolkit，再通过 Game Porting Toolkit 安装运行启动器后，最后才能通过启动器下载 50 多个 GB 的游戏本体。

然后你需要安装 Rosetta，这是苹果为 M1 系统提供的 x86_64 翻译器，以便在 arm64 架构的机器上执行 x86_64 应用程序的指令，你知道原神是 x86_64 的。

`1`	`/usr/sbin/softwareupdate --install-rosetta`

你还需要安装 x86_64 的 Homebrew，因为苹果也通过它来分发 Game Porting Toolkit 的组件（CrossOver Wine）。

可能需要注意的是，如果你已经安装 arm64 版的 Homebrew，它默认应该安装在 /opt/homebrew 下。x86_64 的 Homebrew 默认安装在 /usr/local/Homebrew 下，Homebrew 自身是通过目录来隔离、区分的，请确保你的 arm64 Homebrew 没有安装到其它目录，以防混淆。接下来我也会使用完整路径，以便于区分。

首先进入 x86_64 的 zsh 中，后续安装 Game Porting Toolkit 时的所有命令都应当在该环境下执行。

`1`	`/usr/bin/arch -x86_64 zsh`

从这里开始，请尽量不要退出当前 Shell 或打开新的终端、Shell，因为新的 Shell 默认还是 arm64 环境。如果不慎退出了当前 Shell，你可以再次输入上述命令重新进入 x86_64 环境；如果你忘记了当前的终端是否正处于 x86_64 环境下，可以直接使用 arch 或 uname -m 命令来检查当前的架构。

接下来安装 x86_64 的 Homebrew。记住先检查一遍 /usr/local/Homebrew 目录不存在或者为空，不要与 arm64 的 Homebrew 安装的软件混到一块儿。

1
2

/bin/bash -c "$(/usr/bin/curl -fsSL \
    https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"

我个人不建议把 /usr/local/bin 和 /usr/local/Homebrew/bin 加入到 PATH 中来，还是因为混淆的问题。但是 macOS 默认 PATH 就包含 /usr/local/bin，因为它存在于 /etc/paths 中。从 /etc/paths 中删除对应行，未来打开新的终端的 PATH 中就不会有这一条，是否删除取决于你自己。

接下来的命令涉及到下载和编译，会花费大量的时间，需要耐心等待。

2024-02-15 更新：

或者你还有一个选择，直接安装 Gcenx 预编译的二进制，这位是 DXVK-macOS 的作者：
1
2
brew tap gcenx/homebrew-apple
brew install gcenx/homebrew-apple/game-porting-toolkit
就可以使用了，但是官方提供的 Game Porting Toolkit.dmg 中的 D3DMetal 和一些其它库文件你还是需要手动复制到目录中去。

1
2

/usr/local/bin/brew tap apple/apple http://github.com/apple/homebrew-apple
/usr/local/bin/brew install apple/apple/game-porting-toolkit

如果愿意看编译日志的话，可以在 install 后面加一个 -v，免得漫长的等待使人焦虑。不过我一般都是通过 htop 看进程树观察编译情况，日志刷屏会让我没法一眼看出来当前进度。

下载最新版的 Game Porting Toolkit 完后将其挂载到文件树（双击打开就行），默认情况下会挂载到 /Volumes/Game Porting Toolkit-1.0 目录下，将 lib 目录复制到我们用 Homebrew 编译的 game-porting-toolkit 目录下。Game Porting Toolkit 1.0.4 版本之后将 lib 目录放到了 /Volumes/Game Porting Toolkit-1.0/redist/lib 下，记得自己将下面脚本中的目录改成自己对应的版本。

1
2
3

/usr/bin/rsync --archive \
  '/Volumes/Game Porting Toolkit-1.0/lib' \
  '/usr/local/opt/game-porting-toolkit'

镜像中 bin 目录下还有三个脚本，其实打开看的话，它们只是设置了一下环境变量和过滤了一些日志的简单脚本，而且写得也不太好。比如这些脚本不支持给 exe 传参，然而我们后面启动崩铁必须要给二进制传命令行参数，所以其实我们用不上这三个脚本。不用装这三个脚本直接调用 wine64 也能跑，这里就不装了。

那么到这里 Game Porting Toolkit 已经安装完毕了。如果你进到它在 Homebrew 的目录里观察一下，会发现它其实就是一个 Wine，不过它是苹果修改过后的 CrossOver Wine。

Wine 配置

后面都已经不需要在 x86_64 环境下了。

Wine 的中文字体有必要装一下，不影响游戏本体，但是轻的有遇到其它程序无法显示汉字的情况，严重有原神中打开「祈愿历史」、「版本热点」和「云原神」时卡死整个游戏进程导致无法关闭窗口、以及游戏关闭时也会卡死只能强杀进程的问题。

字体建议用 Winetricks 安装就可以了。Winetricks 就是一个纯 Shell 脚本，所以没有环境依赖问题，用 arm64 的 homebrew 安装就行，不需要指定 x86_64 版本。等装完字体就可以删掉 Winetricks，当然留着它也无妨。

/opt/homebrew/bin/brew install winetricks
WINE=/usr/local/bin/wine64 \
WINESERVER=/usr/local/bin/wineserver \
    /opt/homebrew/bin/winetricks fakechinese

Winetricks 还有很多其它实用的功能，你可以用下面的命令打开图形界面的 Winetricks，这样稍微用户友好一些。图形界面的选项中有一个「选择默认的 Wine 容器」一项，这里稍作解释，如果你跟上面走的话，你的游戏和程序默认都安装在默认容器里，也就是 ~/.wine 这个目录下。你可以在执行 Wine 之前通过设置环境变量 WINEPREFIX 到其它目录来设定你这次运行 Wine 的容器。

1
2
3

WINE=/usr/local/bin/wine64 \
WINESERVER=/usr/local/bin/wineserver \
    /opt/homebrew/bin/winetricks --gui

不建议「安装所有字体」，它的很多资源都丢失没有继续维护了，会中途失败。比如有些字体 404 了（会报错哈希没匹配上，实际上是下载了 404 HTML）、网站服务器挂了（会报错连接多次重试超时失败）。我对着它们调试修复了半天，最后发现没啥用，只需要安装 fakechinese 就能解决问题。

Wine 默认兼容的操作系统是 Windows 7，最好再执行一下 winecfg.exe，或者通过 Winetricks 打开 wine 配置程序，将 Windows 版本设置为 Windows 10。设置界面是图形化的，不难操作。

`1`	`/usr/local/bin/wine64 winecfg.exe`

原神

假如已经将原神安装包放到了 ~/Downloads 目录，直接执行（记得换成自己的目录和文件名）：

1
2

WINEESYNC=1 \
    /usr/local/bin/wine64 ~/Downloads/yuanshen_setup_20230619213504.exe

在启动器安装完后，后续都可以通过下面的命令打开启动器。

1
2

WINEESYNC=1 \
    /usr/local/bin/wine64 'C:\Program Files\Genshin Impact\launcher.exe'

到这里原神已经可以运行了，你可以先启动游戏体验一把 macOS 上的 PC 原神。

2024-02-15 更新：

原神 4.3 版本出现过因为更新使用了 SSE 4.1 指令集导致整个版本无法启动的问题，在官方公告《针对部分PC设备无法进入游戏的情况说明》中也有提及，4.4 版本已经修复了。

原神 4.4 版本需要更新 macOS 到 14.4 Beta 版本才能启动，不清楚是什么原因，感谢评论中 Ysrae1 提供的信息。

⚠️最后提醒一遍，存在封号可能，风险自负。⚠️

另外如果你需要查看帧率、内存使用率、显卡使用率等数据，可以通过设置环境变量执行，同理后面的崩铁也可以这么操作：

1
2
3

MTL_HUD_ENABLED=1 \
WINEESYNC=1 \
    /usr/local/bin/wine64 'C:\Program Files\Genshin Impact\launcher.exe'

但是我们不可能每次开游戏都打开终端敲一段这么长的命令行，为了方便，我们创建一个 macOS 应用来执行脚本启动游戏。打开「脚本编辑器」，新建文稿，输入：

do shell script "
export WINEESYNC=1
/usr/local/bin/wine64 2>&1 \\
        'C:\\Program Files\\Genshin Impact\\launcher.exe' \\
    | /usr/bin/grep --fixed-string D3DM"

点击保存，文件格式选择「应用」即可，更具体内容参见官方脚本编辑器使用手册。

这里加上 grep 是为了防止大量的调试日志输出被 macOS 系统收集，这会导致在游戏退出后 macOS 系统试图弹一个很长的错误对话框，这往往会导致进程卡死。

出于美化目的，你可以为其修改图标，参见官方 macOS 使用手册即可。

图标资源可以从其他地方找一下，比如可以想办法从 PC 原神启动器本身提取，或者直接找网上公开的图标资源等等。

如果你愿意研究怎么制作 macOS 的图标文件的话，这里是一些参考资料：

最后将其拖入 Applications 目录中，安装就算完成了。

崩铁

逻辑基本和原神相同。

已经将崩铁安装包放到了 ~/Downloads 目录，同理执行（记得换成自己的目录和文件名）：

`1`	`WINEESYNC=1 /usr/local/bin/wine64 ~/Downloads/StarRail_setup_gw_20230717.exe`

等待启动器安装完毕、等待游戏本体下载安装完毕。

再后面就无法启动了，因为它有内核级别的反作弊，Wine 执行不了反作弊，于是 Wine 无法启动游戏。

首先屏蔽一些上报信息的域名，执行下述命令在 /etc/hosts 中插入域名：

base64 -d << EOF | sudo tee -a /etc/hosts
CjEyNy4wLjAuMSBsb2ctdXBsb2FkLm1paG95by5jb20KMTI3
LjAuMC4xIHB1YmxpYy1kYXRhLWFwaS5taWhveW8uY29tCg==
EOF

避免因为关键字被检索到，这里用 base64 加密了。

出于对项目的保护目的，这里不提供绕过反作弊的工具，你可以想办法从上下文中推断出信息来；或者通过邮件等方法联系我，我提供链接。

2024-02-15 更新：

崩铁在某个版本之后就无法通过上文提到的反·反作弊工具直接启动，这是绕过工具实现的问题。具体讨论可以参考该工具仓库的 Issue #39。

这里提供一下让它重新跑起来的操作：

使用 unstable-bh-wine-1.2 执行一遍。这样会在 ${WINEPREFIX}/driver_c/users/crossover/Temp 下留下一个目录。这个目录中的文件是关键。

再使用 Game Porting Toolkit 提供的 Wine 直接执行就可以正常启动了。

同样的，通过「脚本编辑器」创建并输入：

do shell script "
export I_WANT_A_BAN=1
export WINEESYNC=1
/usr/local/bin/wine64 2>&1 \\
        'C:\\Program Files\\foo\\bar.exe' \\
        'C:\\Program Files\\Star Rail\\Game\\StarRail.exe' \\
        'C:\\Program Files\\Star Rail\\launcher.exe' \\
    | grep --fixed-string D3DM"

用同样的方法设置图标，就可以正常启动了。

一些问题

原神基本完全可用。原神 3.8 开始似乎删除了反作弊模块校验，所以可以直接用 Game Porting Toolkit 打开，不然也需要其它补丁。

原神之前（Game Porting Toolkit 1.0.2 版本）发现唯一的瑕疵就是草地贴图似乎有点问题，经常不显示或者闪烁。但是不影响游戏本身内容（该在草地上燃烧还是能燃烧）。Game Porting Toolkit 更新到 1.0.4 之后没有再出现过草地问题。

2024-02-15 更新：

原神 4.4 在直接传送到，或者从其它锚点慢慢走到轻策庄左下角锚点（那个一过去野猪就创你的锚点）似乎会遇到问题，导致游戏画面卡死、长时间后自行崩溃退出，并且再也无法进入游戏（卡完整岩然后长时间后崩溃退出）。这里就只能通过其它平台（Windows、手机、云游戏）先进入游戏传送走，才能从 macOS 原神启动。

挺奇怪的，这玩意儿折腾了我好久才意识到是传送点问题，导致我在春运动车上没事干只能闷头睡觉。好像是不能看到凉亭？可能是某个 Bug 导致渲染挂了。没有细致地做过实验具体是什么物件导致的问题。

崩铁使用了腾讯的 AntiCheatExpert 反作弊模块（相比起来，原神和崩三都是自研的），这是个内核模块，就是它导致了 Wine 无法直接运行崩铁。所以上文采用了特殊的绕过方法。

崩铁启动的时候因为这个绕过反作弊工具的限制，只能直接启动游戏本体，无法经过启动器启动。这大多数情况下都不会有问题，但是遇到版本更新的时候，可能需要手动打开启动器去下载新版内容，只需要像命令行启动原神一样打开崩铁启动器就行，然后还需要更新一下反·反作弊工具。这点还好，一般一个版本只需要一次。

崩铁启动的时候会弹窗提醒有封号风险，这是绕过工具的提醒。这是在代码中写死的，你可以通过修改源码自己重新编译绕过。

崩铁启动时音响会炸两下，不太清楚原因，但是游戏中声音是正常的。Game Porting Toolkit 1.0.4 似乎已经修复了这个问题。

还是提醒一遍，在崩铁 1.2 版本以前有大量因为使用了这个绕过方法导致短期中期封号的报告，风险自负。1.2 版本之后都暂时没见到封号，截止目前 1.3 版本，但是我无法做担保，风险自负！

还有退出时很偶尔可能才遇到本体已经关闭，但是 wineserver 还没关的情况，这时候可能需要手动去 killall wineserver 一遍，暂时没有好的解决方法。这个可能不是游戏的原因。

更新日志

2023-07-23

Command Line Tools for Xcode 15 Beta 2
Game Porting Toolkit Beta 2
原神 3.8
崩坏：星穹铁道 1.2

完成文章。

2023-08-31

更新 Command Line Tools 15 Beta 2 到 15 Beta 7
更新 Game Porting Toolkit Beta 2 到 Beta 7
更新原神到 4.0
更新崩坏：星穹铁道到 1.3

原神草地闪烁的问题得到修复。崩铁炸音响问题得到修复。

新增 3.8 版本下半「数据异常」的问题，提及 4.1 中新增的反作弊系统。

2024-02-15

建议 Command Line Tools for Xcode 使用 15.1 正式版本。
更新 Game Porting Toolkit Beta 7 到正式版 1.1。
更新原神到 4.4。
更新崩坏：星穹铁道到 2.0。

macOS 原神似乎没有再遇到「数据异常」问题了，再观察观察，因为 Linux 那边倒是出现了更多奇怪的数据异常，暂时可以通过 kill -SIGSTOP 的手段缓解，这里暂且不提，等 macOS 出现了再尝试解决。

4.1 中提及的反作弊系统更新似乎完全没有影响，删除。

小球放到盒子里的排列组合问题

Sun, 04 Jun 2023 00:00:00 +0000

这也算是个讲烂的话题了，网上搜到一堆。前几天刚复习到了，本想随手水一篇文章，结果又写长了。

其实这篇文章本意是想测试一下评论功能，所以一开始只有下面这张表格。但是还没开始写评论功能就已经上线了，后面就索性补充了一堆解释和证明。

相比于市面上的文章，自认为还是有所拓展的，也就是读完可能会有一些新的收获。比如说对于编号 011，提出了除插板法之外的另一种思路，并且证明两者是等价的；对于 111，也提出了除了最基础的乘法原理之外的另一种思路，并借此引入了一个第二类斯特林数的恒等式。

假设有 $n$ 球 $m$ 盒子：

编号	球不同	盒不同	盒可空	方案数	备注
000	❌	❌	❌	$p(n,m)$	$\displaystyle p(n)=\sum_{k=1}^np(n, k)$ 是整数分拆函数
001	❌	❌	✅	$\displaystyle\sum_{k=1}^mp(n,k)$
010	❌	✅	❌	$\dbinom{n-1}{m-1}$	插板法
011	❌	✅	✅	$\dbinom{n+m-1}{m-1}$	插板法
100	✅	❌	❌	$\genfrac\{\}{0pt}0nm$	$\genfrac\{\}{0pt}0nm$ 是第二类斯特林数
101	✅	❌	✅	$\displaystyle\sum_{k=1}^m\genfrac\{\}{0pt}0nk$
110	✅	✅	❌	$m!\genfrac\{\}{0pt}0nm$
111	✅	✅	✅	$m^n$

整数分拆函数

$p(n)$ 是整数分拆函数，它描述的问题是

将正整数 $n$ 拆成任意正整数之和的方案数。

$p(n, m)$ 是对这个函数的拓展，含义是

将正整数 $n$ 拆成刚好 $m$ 个正整数之和的方案数。

定义就是编号 000 问题本身，事实上两者是同一个问题的不同描述。

根据定义我们有 \begin{equation*}p(n)=\sum_{k=1}^np(n, k)\end{equation*}

$p(n,m)$ 的递推公式 \begin{equation*} p(n,m)=\begin{cases} p(n-1,m-1)+p(n-m,m) & \text{if }0\lt m\lt n \\ \\ 1 & \text{if }m=n \\ \\ 0 & \text{otherwise} \end{cases} \end{equation*}

这个递推式描述了 $n$ 个球放进 $m$ 个盒子的两种可能：

存在一个盒子只有一个球，等价于将剩下 $n-1$ 个球装进 $m-1$ 个盒子，有 $p(n-1,m-1)$ 种方案；
所有盒子都至少有两个球，也就是我们先拿走 $m$ 个球每个盒子装一个，问题就变成了仍然是 $m$ 个盒子但是只有 $n-m$ 个球，每个盒子至少有一个球，也就是 $p(n-m,m)$ 的定义；

很显然这两种可能是互斥的，所以将 $n$ 个球放进 $m$ 个盒子里有 $p(n,m)=p(n-1,m-1)+p(n-m,m)$ 种方案。边界条件还是显而易见的，不再赘述。

部分分拆数：

\begin{equation*} \begin{array}{c|c|} \bm{p(n)} & \bm{n\backslash m} & \bm0 & \bm1 & \bm2 & \bm3 & \bm4 & \bm5 & \bm6 & \bm7 & \bm8 & \bm9 & \bm{10} \\ \hline 1 & \bf0 & 1 \\ 1 & \bf1 & 0 & 1 \\ 2 & \bf2 & 0 & 1 & 1 \\ 3 & \bf3 & 0 & 1 & 1 & 1 \\ 5 & \bf4 & 0 & 1 & 2 & 1 & 1 \\ 7 & \bf5 & 0 & 1 & 2 & 2 & 1 & 1 \\ 11 & \bf6 & 0 & 1 & 3 & 3 & 2 & 1 & 1 \\ 15 & \bf7 & 0 & 1 & 3 & 4 & 3 & 2 & 1 & 1 \\ 22 & \bf8 & 0 & 1 & 4 & 5 & 5 & 3 & 2 & 1 & 1 \\ 30 & \bf9 & 0 & 1 & 4 & 7 & 6 & 5 & 3 & 2 & 1 & 1 \\ 42 & \bf10 & 0 & 1 & 5 & 8 & 9 & 7 & 5 & 3 & 2 & 1 & 1 \\ \end{array} \end{equation*}

另外提到分拆数的算法类文章几乎肯定会提到生成函数和五边形数（因为可以优化复杂度），然而此文长度已经大大超出我的预期，这里便不延伸了。后续如果有时间可能会新开一篇文章再论（应该不会）。

第二类斯特林数

$\genfrac\{\}{0pt}0nm$ 是第二类斯特林数，其定义就是

将 $n$ 个两两不同的元素，划分为 $m$ 个互不区分的非空子集的方案数。

所以编号 100 的问题恰好可以用第二类斯特林数解决。

第二类斯特林数的递推公式 \begin{equation*} \genfrac\{\}{0pt}0nm=\begin{cases} \genfrac\{\}{0pt}0{n-1}{m-1}+m\genfrac\{\}{0pt}0{n-1}m & \text{if }0\lt m\lt n \\ \\ 1 & \text{if }m=n \\ \\ 0 & \text{otherwise} \end{cases} \end{equation*}

对于递推式，它的理解方式和分拆数有所不同，它考虑的是如何从上一个状态转移到当前状态。分类讨论，当插入一个新元素时，有两类方案：

将新元素单独放入一个子集，则其中一个集合只有该新元素，剩下 $n-1$ 个元素放到 $m-1$ 个集合有 $\genfrac\{\}{0pt}0{n-1}{m-1}$ 种可能；
将新元素放入一个现有的非空子集，对于 $n-1$ 个元素划分为 $m$ 个集合的每种情况，新元素都有 $m$ 个集合可以放入，因此有 $m\genfrac\{\}{0pt}0{n-1}m$ 种可能。

边界条件的 0 和 1 两种是显而易见的，不再赘述。

部分斯特林数： \begin{equation*} \begin{array}{c|} \bm{n\backslash m} & \bf0 & \bf1 & \bf2 & \bf3 & \bf4 & \bf5 & \bf6 & \bf7 & \bf8 & \bf9 & \bf10 \\ \hline \bf0 & 1 \\ \bf1 & 0 & 1 \\ \bf2 & 0 & 1 & 1 \\ \bf3 & 0 & 1 & 3 & 1 \\ \bf4 & 0 & 1 & 7 & 6 & 1 \\ \bf5 & 0 & 1 & 15 & 25 & 10 & 1 \\ \bf6 & 0 & 1 & 31 & 90 & 65 & 15 & 1 \\ \bf7 & 0 & 1 & 63 & 301 & 350 & 140 & 21 & 1 \\ \bf8 & 0 & 1 & 127 & 966 & 1701 & 1050 & 266 & 28 & 1 \\ \bf9 & 0 & 1 & 255 & 3025 & 7770 & 6951 & 2646 & 462 & 36 & 1 \\ \bf10 & 0 & 1 & 511 & 9330 & 34105 & 42525 & 22827 & 5880 & 750 & 45 & 1 \\ \end{array} \end{equation*}

编号 000：球相同、盒相同、盒非空

参考整数分拆函数的定义，方案数为 $p(n,m)$。

编号 001：球相同、盒相同、盒可空

和编号 000 类似，但是盒子可以为空。这里分类讨论：

当有且只有 0 个盒子为空的时候，有 $p(n,m)$ 种方案；

当有且只有 1 个盒子为空的时候，有 $p(n,m-1)$ 种方案；

当有且只有 2 个盒子为空的时候，有 $p(n,m-2)$ 种方案；

以此类推，总方案数为 $\displaystyle\sum_{k=1}^mp(n,k)$。

编号 010：球相同、盒不同、盒非空

根据插板法，$n$ 个小球放入 $m$ 个盒子，一共有 $\dbinom{n-1}{m-1}$ 种方案。

这里举例解释插板法：将 $n$ 个小球排在桌子上，比如下面 $n=5$：

\[\circ\qquad\circ\qquad\circ\qquad\circ\qquad\circ\]

中间有 4 个空位置：

\[\circ\underset\wedge\qquad\circ\underset\wedge\qquad\circ\underset\wedge\qquad\circ\underset\wedge\qquad\circ\]

如果我们需要将其分进 3 个盒子，即 $m=3$，相当于要在上面空位中插入两个板，将其分隔成三份，如其中一种方案：

\[\circ\quad\mid\quad\circ\qquad\circ\quad\mid\quad\circ\qquad\circ\]

将其分成了 3 份：1, 2, 2，分别装入三个箱子中。

那么此处一共 $n-1=4$ 个空位，需要选中 $m-1=2$ 个空位插板，因此一共有 $\dbinom 42=6$ 种方案。

\[ \begin{array}{c|ccccccccccc|c} 1 & \quad & \red\circ & \quad\mid\quad & \green\circ & \quad\mid\quad & \color{royalblue}\circ & \qquad & \color{royalblue}\circ & \qquad & \color{royalblue}\circ & \quad & \quad (\red1,\green1,\textcolor{royalblue}3) \\ 2 & \quad & \red\circ & \quad\mid\quad & \green\circ & \qquad & \green\circ & \quad\mid\quad & \color{royalblue}\circ & \qquad & \color{royalblue}\circ & \quad & \quad (\red1,\green2,\textcolor{royalblue}2) \\ 3 & \quad & \red\circ & \quad\mid\quad & \green\circ & \qquad & \green\circ & \qquad & \green\circ & \quad\mid\quad & \color{royalblue}\circ & \quad & \quad (\red1,\green3,\textcolor{royalblue}1) \\ 4 & \quad & \red\circ & \qquad & \red\circ & \quad\mid\quad & \green\circ & \quad\mid\quad & \color{royalblue}\circ & \qquad & \color{royalblue}\circ & \quad & \quad (\red2,\green1,\textcolor{royalblue}2) \\ 5 & \quad & \red\circ & \qquad & \red\circ & \quad\mid\quad & \green\circ & \qquad & \green\circ & \quad\mid\quad & \color{royalblue}\circ & \quad & \quad (\red2,\green2,\textcolor{royalblue}1) \\ 6 & \quad & \red\circ & \qquad & \red\circ & \qquad & \red\circ & \quad\mid\quad & \green\circ & \quad\mid\quad & \color{royalblue}\circ & \quad & \quad (\red3,\green1,\textcolor{royalblue}1) \\ \end{array} \]

编号 011：球相同、盒不同、盒可空

最好先看编号 010 的插板法解释。

因为盒子可空，而直接使用插板法只能解决非空的同类问题，因此需要做一下变换。

考虑先在旧球堆里混入 $m$ 个新球，因为球是相同的，所以不需要标记哪些球是新混入的，只需要记住混入了 $m$ 个球即可。

对 $n+m$ 个球执行插板法，得到 $\dbinom{n+m-1}{m-1}$ 个方案。这里顺带一提根据组合数的性质有 $\dbinom{n+m-1}{m-1}=\dbinom{n+m-1}n$。

已知这些方案中，每个盒子里都至少有一颗球。从每个盒子里拿走一颗球，因为球是相同的，所以不用考虑是否为新混入的球（拿走新球和拿走旧球的两个方案是等价的）。

现在就得到了 $m$ 个可能为空的盒子。

也许读者看到这里可能还有一个小疑问，为什么这里不能和上面类似，对每个盒子是否为空进行讨论呢？答案是可以，但是太麻烦了。因为盒子不同，A 盒非空和 B 盒非空是两种方案，所以我们还需要对每一项乘以组合数（从全部盒子中选出置空盒子的方案数）。最后算出来答案是相同的，只是用插板法更好理解。下面简单推理一下对每个盒子是否为空进行讨论的简化过程：

\begin{equation*} \begin{align*} &\sum_{k=1}^m\binom mk\binom{n-1}{k-1} && \triangleright m\ 个盒子里选\ k\ 个非空，再将\ n\ 个球装入\ k\ 个非空盒子的方案数求和 \\ =&\sum_{k=1}^m\binom m{m-k}\binom{n-1}{k-1} && \triangleright 二项式系数的对称性 \\ =&\sum_{k=0}^{m-1}\binom m{m-1-k}\binom{n-1}k && \triangleright 调整了一下迭代器\ k\ 的范围 \\ =&\binom {n+m-1}{m-1} && \triangleright 范德蒙恒等式 \end{align*} \end{equation*}

编号 100：球不同、盒相同、盒非空

参考第二类斯特林数的定义，方案数为 $\genfrac\{\}{0pt}0nm$。

编号 101：球不同、盒相同、盒可空

和编号 100 类似，但是盒子可以为空。因为盒子相同，所以这里也可以进行分类讨论：

考虑没有盒子为空的情况，则等于 $\genfrac\{\}{0pt}0nm$。

考虑只有一个盒子为空的情况，等于 $\genfrac\{\}{0pt}0n{m-1}$。

考虑只有两个盒子为空的情况，等于 $\genfrac\{\}{0pt}0n{m-2}$。

依此类推，总方案数为 $\displaystyle\sum_{k=1}^{m}\genfrac\{\}{0pt}0nk$。

编号 110：球不同、盒不同、盒非空

首先理解第二类斯特林数 $\genfrac\{\}{0pt}0nm$ 是编号 100 情况的解。

那么对于盒子不同的情况，相当于将编号 100 的所有方案，每个盒子编号后重新排列，每个排列就是本问题的一种方案。

排列共有 $m!$ 种，所以共有 $m!\genfrac\{\}{0pt}0nm$ 种方案。

编号 111：球不同、盒不同、盒可空

因为盒子是不相同的，所以对于每颗球，都有 $m$ 个盒子可以放，因此根据乘法原理，共有 $m^n$ 种方案。

当然和编号 110 将编号 100 的盒子重排列得到答案的逻辑类似。本问题也可以通过编号 101 的结论重排列的方式推导过来，但是两者存在一个差异，那就是两个均为空的盒子是不能参与重排列的，因为在一个排列中将它们交换得到的两个方案并无不同。

注意到在 110 和 100 中盒子均非空，而球和盒均各不相同。所以在一个排列中，任何两个盒子 A 和 B 中均有球，记为球 1 和球 2，而球在 A 盒或 B 盒肯定是两种方案 A1B2 和 A2B1，所以不论哪种方案都有 $m!$ 种排列。

所以这里存在着一些差异，那就是我们在从 $m$ 个盒子中选定 $k$ 个非空盒子的时候，还需要对其进行排列，也就是 $m^{\underline k}$ 种。这里 $m^{\underline k}$ 是递降阶乘，定义为 $m^{\underline k}=\dfrac{m!}{(m-k)!}=m(m-1)(m-2)\cdots(m-k+1)$（就是排列数 $m$ 取 $k$）。

从这里可以从逻辑上推导出另一个关于第二类斯特林数的恒等式：

\begin{equation*} \sum_{k=1}^mm^{\underline k}\genfrac\{\}{0pt}0nk=m^n \end{equation*}

如果你打开下面的参考资料第二类斯特林数，你会发现维基百科中写的是 $\displaystyle\sum_{k=1}^n\genfrac\{\}{0pt}0nk(x)_k=x^n$，和上面的唯一区别是 $\displaystyle\sum$ 迭代器 $k$ 是到 $n$ 为止的。不要紧，只要 $k\gt n$ 或者 $k\gt m$ 满足任意一个，结果都是 $0$，所以两者是等价的，这里其实应该是 $\min(n,m)$。

参考资料

GCC 部分内建位运算函数轮子

Thu, 20 Oct 2022 00:00:00 +0000

某个空虚寂寞的晚上，随便造点轮子，只是常用的二进制位运算的函数而已。实现不一定是常数最优的，可读性优先。

裸的打表、分块打表、不到 log 级别的表不写，不屑。

Counting Trailing Zeros

__builtin_ctz，返回从最低位开始的连续的 0 的个数；如果传入 0 则行为未定义。

_BitScanForward ，Visual Studio 中的内建函数，等价于 GCC 的 __builtin_ctz。

朴素

int ctz64(uint64_t x) {
  for (int i = 0; i != 64; ++i)
    if (x >> i & 1) return i;
  return 0;
}

二分

int ctz64(uint64_t x) {
  int r = 63;
  x &= ~x + 1;
  if (x & 0x00000000FFFFFFFF) r -= 32;
  if (x & 0x0000FFFF0000FFFF) r -= 16;
  if (x & 0x00FF00FF00FF00FF) r -= 8;
  if (x & 0x0F0F0F0F0F0F0F0F) r -= 4;
  if (x & 0x3333333333333333) r -= 2;
  if (x & 0x5555555555555555) r -= 1;
  return r;
}

这里用到了一个位运算技巧 x & ~x + 1 可以直接提取出 x 的最低设置位（Lowest Set Bit）。这是一个比较巧妙的方法，在 CTZ 中被广泛使用。它在树状数组中被也应用于定位前继节点（向前走，求前缀和）或者父节点（向后走，向上更新状态）。一个小细节是在补码表示的情况下，~x + 1 和 -x 是等价的，本文用 ~x + 1 更清晰。

后面几行就是二分判断最低设置位在二进制表达的哪个位置。第 4 行判断是前半截还是后半截，第 5 行将 64 位二进制数分成两个 32 位，判断在 32 位的前半截还是后半截，依次类推。顺序反过来或者从 0 开始往上加都是可以的。

IEEE-754 性质

int ctz64(uint64_t x) {
  union {
    double f;
    uint64_t i;
  } v = {
    .f = x & ~x + 1,
  };
  return (v.i >> 52) - 1023;
}

利用了 IEEE-754 中定义的 binary 格式，在遇到 2 的幂次时，它指数域的值减去置偏值就是 2 右上那个指数，也就是我们需要求的值。上面的代码里没有管符号位，因为我们用的是 uint64_t，如果不是无符号整数可能要针对负数进行处理一下。

de Bruijn 序列性质（映射查表）

int ctz64(uint64_t x) {
  static const int bit_perm[64] = {
     0,  1,  2,  7,  3, 13,  8, 19,  4, 25, 14, 28,  9, 34, 20, 40,
     5, 17, 26, 38, 15, 46, 29, 48, 10, 31, 35, 54, 21, 50, 41, 57,
    63,  6, 12, 18, 24, 27, 33, 39, 16, 37, 45, 47, 30, 53, 49, 56,
    62, 11, 23, 32, 36, 44, 52, 55, 61, 22, 43, 51, 60, 42, 59, 58,
  };
  return bit_perm[0x218A392CD3D5DBFUL * (x & ~x + 1) >> 58];
}

这种方法本质上是找到了一个巧妙的映射函数，利用了 de Bruijn 序列的一个性质将 64 个 2 的幂 $\displaystyle\left\{2^k\middle|k\in[0,64)\cap\mathbb Z\right\}$ 双射回 $[0,64)\cap\mathbb Z$ 区间内，结合之前的 x & x + 1 技巧，我们就可以直接得到答案。

代码中的魔数 0x218A392CD3D5DBFUL 就是 B(2, 6) 的 de Bruijn 序列，如果将它转化为二进制并且头尾相接成环，使用 6 位的窗口滑动过去，可以发现每个窗口都不同。所以将它左移 063 位，每次都能拿到不同的 6 位数字（无论取哪部分的 6 位）。这样的话只需要获取到 x 的最低设置位，因为它本身是一个 2 的幂，它乘以任何数都等价于左移一个 CTZ。又因为是双射，所以肯定是覆盖满值域定义域的，只需要把 063 对应 2 的几次幂全部求出来，存到数组里再映射就行。

关于 de Bruijn 具体可以参考维基百科 de Bruijn sequence，我这里将生成 128 位 de Bruijn 序列和它的双射表的代码放上来，64 位改个参数就行：GitHub Gists。

Find First Set

__builtin_ffs ，返回最低的非 0 位的下标，下标从 1 开始计数；如果传入 0 则返回 0 。

除 0 以外，满足恒等式 __builtin_ffs(x) == __builtin_ctz(x) + 1 ，懒得罗嗦了。

int ffs64(uint64_t x) {
  if (x == 0) return 0;
  return ctz64(x) + 1;
}

Count Leading Zeros

__builtin_clz，返回从最高位开始连续的 0 的个数；当传入 0 则行为未定义。

_BitScanReverse，Visual Studio 中的内建函数，等价于 __builtin_clz。

一个数学特性是 $\mathrm{clz}\ x+\lfloor\log_2 x\rfloor+1=类型位宽$。

朴素

int clz64(uint64_t x) {
  for (int i = 0; i != 64; ++i)
    if (x >> 63 - i & 1) return i;
}

二分

int clz64(uint64_t x) {
  int r = 0;
  if ((x & 0xFFFFFFFF00000000) == 0) r += 32, x <<= 32;
  if ((x & 0xFFFF000000000000) == 0) r += 16, x <<= 16;
  if ((x & 0xFF00000000000000) == 0) r += 8,  x <<= 8;
  if ((x & 0xF000000000000000) == 0) r += 4,  x <<= 4;
  if ((x & 0xC000000000000000) == 0) r += 2,  x <<= 2;
  if ((x & 0x8000000000000000) == 0) r += 1,  x <<= 1;
  return r;
}

这个还是比较好理解的，不多解释了。

IEEE-754 性质

因为 IEEE-754 会自动调整成科学计数法，所以直接将数字转为浮点数就可以使用了。可能需要担心的就是非规格化浮点数，但是我们处理的都是整数，碰不到。

int clz64(uint64_t x) {
  union {
    double f;
    uint64_t i;
  } v = {
    .f = x,
  };
  return 1086 - (v.i >> 52);
}

首先也是拿到指数域，减去置偏值，得到的是 $\left\lfloor\log_2 x\right\rfloor$，我们要求前缀 0 个数，还要用 63 减一下，也就是 63 - ((v.i >> 52) - 1023) 化简后就是上面的。

同样这里也没有考虑负数的符号位，如果有负数直接返回 0 好了。

de Bruijn 序列性质（映射查表）

int clz64(uint64_t x) {
  static const int bit_perm[64] = {
    63, 62, 61, 56, 60, 50, 55, 44, 59, 38, 49, 35, 54, 29, 43, 23,
    58, 46, 37, 25, 48, 17, 34, 15, 53, 32, 28,  9, 42, 13, 22,  6,
     0, 57, 51, 45, 39, 36, 30, 24, 47, 26, 18, 16, 33, 10, 14,  7,
     1, 52, 40, 31, 27, 19, 11,  8,  2, 41, 20, 12,  3, 21,  4,  5,
  };
  x |= x >> 32;
  x |= x >> 16;
  x |= x >> 8;
  x |= x >> 4;
  x |= x >> 2;
  x |= x >> 1;
  x ^= x >> 1;
  return bit_perm[0x218A392CD3D5DBF * x >> 58];
}

和 ctz 本质是一样的，先单独拎出最高设置位，中间那一段 |= 就是干这个的，逻辑是把最高设置位右边填满 1，然后减一下，就只剩最高设置位了。

其它的逻辑和 de Bruijn 是一样的，代码生成改一下之前的脚本就可以了，这里就略过了。

Count Leading Redundant Sign Bits

__builtin_clrsb，返回从最高位（MSB）开始和符号位相同的位数。

int clrsb64(int64_t x) {
  if (x == 0 || x == -1) return 63;
  return clz64(x ^ x >> 63);
}

很简单，利用有符号整数的右移运算符会用符号填充高位的性质，如果本来是负数那么 x >> 63 就是 -1，如果本来是非负数那就是 0。然后和原数异或一次，如果原数是负数那所有 1 被翻转为 0，如果原数是正数那保持不变。最后求一次 CLZ 即可。

Population Count

__builtin_popcount 统计二进制位中 1 的个数。

比较常用，研究比较多，骚优化不少。

朴素

int popcount64(uint64_t x) {
  int r = 0;
  do r += x & 1;
  while (x >>= 1);
  return r;
}

一个优化

int popcount64(uint64_t x) {
  int r = 0;
  for (; x; x &= x - 1) ++r;
  return r;
}

x & x - 1 的作用是将最低设置位置 0。很好理解，x - 1 在遇到最低位是 0 的时候会不停向上借位，直到碰到一个 1 也就是最低设置位为止。最后结果最低设置位以及更低位都被翻转，然后和原数按位与一下就把最低设置位置 0 了。

这样迭代次数和参数二进制表达中 1 的个数相同，稍微有些优化。

二分

int popcount64(uint64_t x) {
  x = (x & 0x5555555555555555) + (x >> 1  & 0x5555555555555555);
  x = (x & 0x3333333333333333) + (x >> 2  & 0x3333333333333333);
  x = (x & 0x0F0F0F0F0F0F0F0F) + (x >> 4  & 0x0F0F0F0F0F0F0F0F);
  x = (x & 0x00FF00FF00FF00FF) + (x >> 8  & 0x00FF00FF00FF00FF);
  x = (x & 0x0000FFFF0000FFFF) + (x >> 16 & 0x0000FFFF0000FFFF);
  x = (x & 0x00000000FFFFFFFF) + (x >> 32 & 0x00000000FFFFFFFF);
  return x;
}

思路是这样，先把二进制按 2 位分组，每个 0x5 即 0b0101 就是分组结果，然后将这每两位中的 0 部分和 1 部分相加。再将加起来的结果按 4 位分组，每个 0x3 即 0b0011 就是分组结果，再将这 4 位中两位 0 部分代表数字和两位 1 部分代表数字相加。依此类推。

或者可以这么理解，先将输入看作 4 进制数字，然后将高位和低位相加；再将相加的结果看作 16 进制数字，然后将高位和低位相加；再将相加的结果看作 256 进制数字，然后将高位和低位相加；依次类推。之所以这么理解，是为了下面的一个优化：

int popcount64(uint64_t x) {
  x = (x & 0x5555555555555555) + (x >> 1 & 0x5555555555555555);
  x = (x & 0x3333333333333333) + (x >> 2 & 0x3333333333333333);
  x = (x & 0x0F0F0F0F0F0F0F0F) + (x >> 4 & 0x0F0F0F0F0F0F0F0F);
  return x % 255;
}

这个优化是在第 4 行这一步过后直接 mod 255 就是结果。因为 $m^k\equiv1\pmod{m-1}$ ，所以 $m$ 进制的数字 $\overline{a_na_{n-1}\cdots a_3a_2a_1}$ 有 $\sum\limits_{1\le k\le n}a_km^k\equiv\sum\limits_{1\le k\le n}a_k\pmod{m-1}$ 就是按位和。上面已经分析过第三步之后就已经拿到一个 256 进制了，所以直接 mod 255 就是答案。而更上一步则需要 mod 16，这肯定会有问题，因为 64 bits 的 popcount 最高是 64，mod 16 显然会出错。

类似的，在算到第四轮的时候完全不需要维护更高位的部分，因为单个 16 进制已经可以保存下当前完整的 1 计数数了。只需要直接低位部分加上高位部分，最后截取低 8 位即可。该变种仍可继续优化，最后求和的部分可以一个乘法达成：

int popcount64(uint64_t x) {
  x -= x >> 1 & 0x5555555555555555;
  x = (x & 0x3333333333333333) + (x >> 2 & 0x3333333333333333);
  x = x + (x >> 4) & 0x0F0F0F0F0F0F0F0F;
  return x * 0x0101010101010101 >> 56;
}

第 2 行因为是按照 2 bits 分组的，所以它的含义，我们只需要枚举 0~4 的映射就可以了，可以看出来和原来是等价的。这么做是为了减少一次运算。

from	into
00	0
01	1
10	1
11	2

第三行没变，第四行就是去掉了维护更高位部分的逻辑，上面说过 16 进制已经存得下了。而最后一行乘以 0x0101010101010101 是将每个 0xF 分组部分全部累加到最高的 8 位中，然后直接舍弃低位截取最高字节（右移 56 位）即可。

Parity

__builtin_parity 就是求 __builtin_popcount 的奇偶性。

偷懒

1
2
3

int parity64(uint64_t x) {
  return popcount64(x) & 1;
}

二分

int parity64(uint64_t x) {
  x ^= x >> 1;
  x ^= x >> 2;
  x ^= x >> 4;
  x ^= x >> 8;
  x ^= x >> 16;
  x ^= x >> 32;
  return x & 1;
}

一个优化是部分打表，在 x 的值比 16 小了之后直接用表即可，由于 parity 只会返回 0 或 1，因此可以压位。

参考资料

C++ CRTP 简介

Tue, 18 Oct 2022 00:00:00 +0000

看标题就知道我打算重写一遍之前的 CRTP 文章，加上既然 C++23 快要出来了，我也研究了一下 C++23 的 CRTP 能不能有一些变化。

题外话：Hugo 的 date 用的特么的是 UTC 时间，过了零点后我早上八点前写的文章它默认不会发布，得加上 buildFuture = true 这个配置项才会发布，害我调试了半天。

另外之前备份的 WordPress 数据也是直接 mysqldump 一把梭下来的，全是压成一片的转义符号，为了拿到正常的数据我还得先扔回 MySQL 里，大无语。

所谓 CRTP

所谓 CRTP，全称是 Curiously recurring template pattern，中文叫“奇异模板递归模式”，有着很奇异的名字。为什么说它奇异呢，是因为一个派生类的基类，它的模板参数中竟然有这个派生类自己。不过虽然名字里有一个奇异，它现如今已经被广泛地在各种类库中被使用了，甚至标准库中都有使用的例子，比如我们的 std::enable_shared_from_this，具体功能这里就不介绍了。

另一项可能可以说是进入标准库的来自于 Boost 的 operators.hpp 头文件，它也大量使用了 CRTP 的特性。不过这里说法其实并不准确，算是我硬凑到 C++ 的一个例子，进核心语言特性的是它其中的一部分 boost::less_than_comparable 这一族比较运算符的功能，进标准后被叫做三路比较运算符 operator<=>，也就是实现一个 operator<=> 编译器就能自动实现其它的比较运算符。

CRTP 的主要作用往往是基类需要获取一些派生类信息，或许是成员，或许是方法，或许是类型本身，再通过在基类中实现方法继承来扩展派生类本身，而且可以避免虚函数、动态分派带来的额外运行时代价的问题。比如 std::enable_shared_from_this 就是获取派生类类型本身来给派生类生成 shared_from_this 方法；而 boost::less_than_comparable 就是获取一个派生类方法 operator< 来给派生类生成其它的比较运算符。在其它语言中和 CRTP 比较类似的概念是 interface 的 default implementation，相比于此 CRTP 实现起来更加奇异一些，毕竟其非语言特性，只是 CRTP 没有运行时代价。

CRTP 往往因为用到了继承的能力而被误用，这里注意它不能被用于动态调度，也就是将一系列继承于不同模板参数的同一个 CRTP 模板类放到同一个容器里。有些人为了能运行时调度而加入了一个总的基类使得所有 CRTP 虚继承自此，这是完全错误的。CRTP 是用来消除运行时多态的，加入全局虚基类会凭空创造运行时代价，这就完全抹煞了 CRTP 的作用。

再说一遍，它的主要能力类似于其它语言的 default implementation，但它不是 interface。不要想着对不同的派生于 CRTP 的类型进行统一管理，因为模板参数的存在，它们不是相同的类型，不要对其进行虚继承等操作。就好像你不会觉得 std::vector<int> 和 std::vector<long> 是相同类型一样，它们也不会继承自同一个虚基类（虽然实现上确实会有非虚继承，但那是为了实现通用代码，避免实例化导致的代码膨胀，优化编译速度和产物体积）。

从委托模式开始

为什么选用委托模式，因为这是我觉得比较相似的一种模式，它还出现在 Head First Design Pattern 一书中，应该是属于比较简单常见的一种模式。

来简单实现一个会叫的鸭子类型：

interface QuackBehavior {
    public void quack();
}

class Quack implements QuackBehavior {
    public void quack() { System.out.println("Quack"); }
}

// 哑巴
class MuteQuack implements QuackBehavior {
    public void quack() { /* pass */ }
}

// 正常鸭子
public abstract class Duck {
    QuackBehavior quackBehavior;

    public Duck(QuackBehavior quackBehavior) {
        this.quackBehavior = quackBehavior;
    }

    public void quack() { this.quackBehavior.quack(); }
}

class MallardDuck extends Duck {
    public MallardDuck() { super(new Quack()); }
}

// 橡皮鸭子
class RubberDuck extends Duck {
      public RubberDuck() { super(new MuteQuack()); }
}

它将“叫”的行为抽离出来，将不同类型的鸭子抽象成多个行为的组合，这样我们就不再关心鸭子到底是什么，我们只关心它的行为。将每个行为，比如“叫”、“游”等委托给具体的行为类型来执行，所以它被叫做委托模式。

不过其实这只是继承或者说组合的能力，还没到 CRTP 发挥自己作用的地方。只是 Java 没法多继承，所以搞了个委托模式来做。当然，现在的 Java 也支持 default implementation，咱先不讨论这个。

C++ 中的 CRTP

在 C++ 里，我们可以直接多继承。实现上面的功能甚至不需要虚函数，直接继承就好了，Java 是默认虚函数、禁止多继承，那没办法。

struct Quack {
  void quack() { std::println("quack"); }
};

struct Dump {
  void quack() { std::println("silent"); }
};

struct Swim {
  void swim() { std::println("swim"); }
};

struct Float {
  void swim() { std::println("float"); }
};

// 绿头鸭，会叫，也会游泳
struct MullardDuck: Quack, Swim {};

// 橡胶鸭，不会叫，也不会游泳
struct RubberDuck: Dump, Float {};

int main() {
  MullardDuck mullard{"duck 007"};
  mullard.quack();

  RubberDuck doll{"007's duck doll"};
  doll.swim();
}

但是，当我们的基类需要依赖派生类的实现，那似乎就必须要虚函数了——不要在意菱形继承。

// 我们需要派生类实现 name 方法，来给基类提供额外的信息。
struct Named {
  // std::string_view 是 c++17 的，不过可以用 boost 的平替，所以不用太在意
  virtual std::string_view name() = 0;
};

struct Quack: virtual Named {
  void quack() { std::println("{} quacks", this->name()); }
};

struct Dump: virtual Named {
  void quack() { std::println("{} keeps silence", this->name()); }
};

struct Swim: virtual Named {
  void swim() { std::println("{} swims", this->name()); }
};

struct Float: virtual Named {
  void swim() { std::println("{} floats", this->name()); }
};

这样就简单了，只要派生类实现了 Named，也就是 name 方法，那么就可以无痛继承前面几个类型，并可以调用相应的 quack 或 swim 方法。

struct MullardDuck: Quack, Swim {
  MullardDuck(std::string name): name_{std::move(name)} { }

  virtual std::string_view name() override { return this->name_; }

private:
  std::string name_;
};

struct RubberDuck: Dump, Float {
  RubberDuck(std::string name): name_{std::move(name)} { }

  virtual std::string_view name() override { return this->name_; }

private:
  std::string name_;
};

但是众所周知，这个世界上有两件事是我们 c++er 所厌恶的，一是菱形继承，二是额外的运行时代价。这就是 CRTP 能帮我们消灭的敌人。

template <typename Named> struct Quack {
  void quack() {
    std::println("{} quacks", static_cast<Named *>(this)->name());
  }
};

template <typename Named> struct Dump {
  void quack() {
    std::println("{} keeps silence", static_cast<Named *>(this)->name());
  }
};

template <typename Named> struct Swim {
  void swim() {
    std::println("{} swims", static_cast<Named *>(this)->name());
  }
};

template <typename Named> struct Float {
  void swim() {
    std::println("{} floats", static_cast<Named *>(this)->name());
  }
};

发生了什么？我们给每个基类都添加了一个模板参数，而在定义派生类的时候，我们将派生类本身作为模板参数传入：

struct MullardDuck: Quack<MullardDuck>, Swim<MullardDuck> {
  MullardDuck(std::string name): name_{std::move(name)} { }

  std::string_view name() { return this->name_; }

private:
  std::string name_;
};

struct RubberDuck: Dump<RubberDuck>, Float<RubberDuck> {
  RubberDuck(std::string name): name_{std::move(name)} { }

  std::string_view name() { return this->name_; }

private:
  std::string name_;
};

在基类的实现中，由于 this 中没有 name 方法，这个方法在派生类——也就是模板参数 Named 中，所以我们需要将 this 强转回 Named *，然后调用派生类 Named 的 name 方法。这当然是没问题的，因为在实例化这些方法的时候，派生类已经被完整定义了，尽管在继承的时候还没有。这里没有菱形继承，也没有虚函数和虚继承，一切都是那么美好。

因为我们编码阶段保证了 Named 是 Quack<Named> 派生类，所以也不需要 dynamic_cast，这里必然能 static_cast 成功。读者可以试着自行修改一下代码，观察如果模板参数 Named 填错类型，或者派生类本身没有实现 name 方法，会报什么错误。

另外，正如前文所说，当我们已经有了派生类类型的情况下，获取派生类方法当然是最灵活最常见的一种用途，只是不仅限于此，在基类中同样可以拿到派生类的成员变量、静态成员或方法等等，只是不常用罢了。

最后需要注意的是，模板参数不同的基类不是同一个类型，所以我们没法使用基类指针来进行动态分派。这也没关系，CRTP 本来就不是用来帮助动态分派的，如果需要做一些动态的工作，那就需要另外继承了，也不在本文的话题之内。

更摩登的 CRTP

C++ 在与时俱进，CRTP 也随着进化，这里简单介绍一些随着 C++ 更新给 CRTP 带来的优化。

C++11 中，我们可以利用模板参数包来简化派生类的定义。

template <template <typename ...> class Bases>
struct Duck: Bases<Duck<Bases...>>... {
  Duck(std::string name)
      : name_{std::move(name)}
      , Bases<Duck<Bases...>>{*this}... {
  }

  std::string_view name() {
    return this->name_;
  }
private:
  std::string name_;
};

那么使用的时候只需要如下操作，就可以按需组装出不同的鸭子来了。

// 只有名字的鸭子（只有 name 方法）
using NamedDuck = Duck<>;               
// 能游泳的哑巴鸭子（有 quack, swim, name 方法）
using SwimDumpDuck = Duck<Dump, Swim>;  
// 能叫会飞会游泳的鸭子（有 quack, fly, swim, name 方法）
using FlyDuck = Duck<Quack, Fly, Swim>;

这里模板展开的逻辑，大意就是 Duck 接收 template template parameter，并自动从这些参数中派生，且将自身完整类型填到基类的模板参数中。因此在使用的时候只需要将没有模板参数的基类作为参数填入模板中，不需要将自己再填进去，可以很大地简化使用、批量生成新类型。

后面的 C++20 和 C++23 内容在旧的文章中没有提到，是全新的。

到了 C++20，我们有了 concept，可以放到基类中约束派生类的实现，比如要求派生类提供某个方法的实现，用来优化代码错误诊断信息，对实现者或者 IDE 本身也有更好的提示作用。不过其实因为定义 CRTP 基类的时候派生类还没有被定义，基类上的 concept 获取不到派生类的方法，所以会失败。我们只能通过将 requires 子句放到基类方法上，通过延后实例化来绕过这个限制，只是如此又显得有些鸡肋了。

template <typename T>
concept Named = requires(T value) {
  { value.name() } -> std::same_as<std::string_view>;
};

// ❌ 会直接编译失败，提示 Duck 没有 name 方法，因为继承的时候还没有方法定义
template <Named T>
struct Quack {
  void quack() {
    std::println("{} quacks", static_cast<Named *>(this)->name());
  }
};

// ✅ 可以编译通过，但是只有在使用 quack 方法时才会实例化，并在不满足时报错
template <typename T>
struct Quack {
  void quack() requires Named<T> {
    std::println("{} quacks", static_cast<Named *>(this)->name());
  }
};

在 C++23 中，有了所谓的显式对象形参（Deducing this），我们首先可以对代码稍作简化，去掉代码中的 static_cast。

template <typename T>
struct Quack {
  void quack(this T &self) requires Named<T> {
    std::println("{} quacks", self.name());
  }
};

然后可以再激进一些，既然可以在函数声明中直接指定 this 的类型，那何必还需要在外面的 struct 上套一层 template 呢。这句话象征着，我们的 CRTP 甚至再也不需要 Curiously，不需要 Recurring，甚至不需要 Template：

struct Quack {
  template <typename Self>
  void quack(this Self &self) requires Named<T> {
    std::println("{} quacks", self.name());
  }
};

以至于在继承的时候，直接就不再需要传递自身类型作为参数了。

struct Duck: Quack {
  std::string_view name() {
    return this->name_;
  }
  std::string name_;
}

这个变化虽然不大，但确实称得上是意义非凡。

鸭子何必是鸭子

我们把思路打开，讨论一下 CRTP 在更具体场景下的应用。除了文章开头举的例子：std::enable_shared_from_this 和 boost::less_than_comparable 家族，还有一些比较直观的实例。

比如说，当我们提供了一个抽象的 Reader 接口，实现者可以为本地文件句柄、为 TCP 套接字，甚至可以为内存的一段 Buffer 实现 Reader 接口。

一方面，我们希望 Reader 接口本身的约束非常简单，只需要实现者提供一个可中断的 ssize_t read(uint8_t buffer[], size_t n) 实现，以降低实现者的负担。

但是另一方面，我们又希望 Reader 接口提供的方法要丰富，以提升调用方的使用体验。比如说：带超时的读 read_timeout 方法、读到某个条件满足为止 read_until 方法、不中断读到 EOF 方法 read_to_end、用户提供 buffer 的和实现来 alloc 内存的（比如直接返回 std::string 的方法）等等等等。

当然，我们注意到上面提到的一些方法其实都依赖最基础的 read 方法，只要用户实现了 read 方法本身，我们就有办法增加一些额外的逻辑来帮助实现这些额外的方法——这便明显是 CRTP 的用武之地。

另外，我也说过我最近在写 Rust。作为同为系统级编程语言的 Rust，为什么不见人们提及 CRTP 在 Rust 中的实现呢？暂且不论 Rust 的模板（泛型参数）做不到 C++ 这种表达能力，根本原因还是在于 Rust 语言特性就已经覆盖了 CRTP 的功能，简单了解一下 trait 的 default implementation 就能明白为什么 CRTP 在 Rust 中并没有什么价值，完全没必要采用 C++ 这种委曲求全的方式。而且其实我上面所说的 Reader 接口，就是参考 Rust 的 std::io::Read 的。

与之类似的，之所以我们不在 C++ 中使用 Java 中泛用的一些设计模式，也是因为语言本身可能就提供了更加便利或者高效的工具，不需要去绕这些远路。将一门语言的经验强行套到另一门语言上并不一定适合。

后记

关于 CRTP，我之前的旧的博文中提到很多人对 CRTP 作用理解为消除动态调用，但是最后实践上却又为了能将相似的对象储存到一起，使用虚函数加继承的方法储存指针动态派发，如此一来这里其实完全没有利用到静态分派的性能优势，而且和 CRTP 的真正作用相去甚远，因此对某些文章提出了批判。不过我最近又搜了一下，那都是 2016 或者更早以前的旧文章了，我看最新的搜索结果大多是正确的，我之前批评的那个博客也已经不存在了（其实换了一个域名，现在找到了）。

而且在老的那篇文章中，我自己对于 CRTP 的理解也存在一些误区。在之前的文章中，虽然我意识到 CRTP 是可以通过派生类的实现扩展派生类，但是我还是将 CRTP 和继承本身的作用搞混了。就比如我旧文章中一直在提的 CRTP 可以“模块化”鸭子类型，通过不断继承来附加新的功能，然而其实模块化是继承提供的能力，CRTP 只是利用了继承带来的模块化特性。我在比较早（可能数年前）就意识到了这点错误，只是一直懒于重新修改我的文章改正。

而我在最近一周重新拾起我的博客，一大原因是 C++23 又出来了，我在观看 cppcon 的时候注意到了 std::forward_like 这个新方法，学习的时候又被引导到了 deducing this 这个特性上，过程中突然意识到这个特性可以用来简化 CRTP。又恰好碰到这段时间我 WordPress 博客挂了，然后就想索性从头开始写一下 CRTP，也好更正一下以前的错误。

不过话说回来，deducing this 的最主要作用还是用来在 Lambda 中递归，以前的 C++ Lambda 表达式可不是那么容易写递归的，这就不在这篇文章的讨论范围之内了。

博客迁移

Sat, 15 Oct 2022 00:00:00 +0000

之前那个 xr1s.me 大概是 OOM 了挂了，本来就是加了 Swap 才能跑的，其实重启一下应该就好了。

但是因为工作后也不怎么写博客，服务器都直接懒得维护了，现在打算就静态简单搞搞吧。目前用的是 Hugo，没有特别的理由，因为看到了个喜欢的主题——众所周知，我喜欢衬线体，显得我好像很有文化一样。

发里浮哨。

旧的博文都已经备份了，可能自己看一遍有没有大的问题再发出来，不过评论就没了。

目前业余时间主要在折腾 Rust，以后可能 Rust 文章会有一些。不过第一篇正经的文章可能会把 C++23 后的 CRTP 写一写。

后面测试一下代码和数学公式。

import asyncio

import httpx


async def main():
    async with httpx.AsyncClient() as client:
      await client.get("https://xr1s.me")


if __name__ == "__main__":
    asyncio.run(main())

名称	积分形式	微分形式
高斯定律	$\displaystyle\oiint_{\partial\Omega}\mathbf E\cdot\mathrm d\mathbf S=\frac1{\varepsilon_0}\iiint_\Omega\rho\ \mathrm dV$	$\displaystyle\nabla\cdot\mathbf E=\frac\rho{\varepsilon_0}$
高斯磁定律	$\displaystyle\oiint_{\partial\Omega}\mathbf B\cdot\mathrm d\mathbf S=0$	$\displaystyle\nabla\cdot\mathbf B=0$
法拉第电磁感应定律	$\displaystyle\oint_{\partial\Sigma}\mathbf E\cdot\mathrm d\mathbf\ell=-\frac{\mathrm d}{\mathrm dt}\iint_\Sigma\mathbf B\cdot\mathrm d\mathbf S$	$\displaystyle\nabla\times\mathbf E=-\frac{\partial\mathbf B}{\partial t}$
麦克斯韦-安培定律	${\displaystyle\oint_{\partial\Sigma}\mathbf B\cdot\mathrm d\mathbf\ell=\mu_0\left(\iint_\Sigma\mathbf J\cdot\mathrm d\mathbf S+\varepsilon_0\frac{\mathrm d}{\mathrm dt}\iint_\Sigma\mathbf E\cdot\mathrm d\mathbf S\right)}$	${\displaystyle\nabla\times\mathbf B=\mu_0\left(\mathbf J+\varepsilon_0\frac{\partial\mathbf E}{\partial t}\right)}$

名称	积分形式	微分形式
高斯定律	\(\displaystyle\oiint_{\partial\Omega}\mathbf E\cdot\mathrm d\mathbf S=\frac1{\varepsilon_0}\iiint_\Omega\rho\ \mathrm dV\)	\(\displaystyle\nabla\cdot\mathbf E=\frac\rho{\varepsilon_0}\)
高斯磁定律	\(\displaystyle\oiint_{\partial\Omega}\mathbf B\cdot\mathrm d\mathbf S=0\)	\(\displaystyle\nabla\cdot\mathbf B=0\)
法拉第电磁感应定律	\(\displaystyle\oint_{\partial\Sigma}\mathbf E\cdot\mathrm d\mathbf\ell=-\frac{\mathrm d}{\mathrm dt}\iint_\Sigma\mathbf B\cdot\mathrm d\mathbf S\)	\(\displaystyle\nabla\times\mathbf E=-\frac{\partial\mathbf B}{\partial t}\)
麦克斯韦-安培定律	\({\displaystyle\oint_{\partial\Sigma}\mathbf B\cdot\mathrm d\mathbf\ell=\mu_0\left(\iint_\Sigma\mathbf J\cdot\mathrm d\mathbf S+\varepsilon_0\frac{\mathrm d}{\mathrm dt}\iint_\Sigma\mathbf E\cdot\mathrm d\mathbf S\right)}\)	\({\displaystyle\nabla\times\mathbf B=\mu_0\left(\mathbf J+\varepsilon_0\frac{\partial\mathbf E}{\partial t}\right)}\)

编号	球不同	盒不同	盒可空	方案数	备注
000	❌	❌	❌	\(p(n,m)\)	\(\displaystyle p(n)=\sum_{k=1}^np(n, k)\) 是整数分拆函数
001	❌	❌	✅	\(\displaystyle\sum_{k=1}^mp(n,k)\)
010	❌	✅	❌	\(\dbinom{n-1}{m-1}\)	插板法
011	❌	✅	✅	\(\dbinom{n+m-1}{m-1}\)	插板法
100	✅	❌	❌	\(\genfrac\{\}{0pt}0nm\)	\(\genfrac\{\}{0pt}0nm\) 是第二类斯特林数
101	✅	❌	✅	\(\displaystyle\sum_{k=1}^m\genfrac\{\}{0pt}0nk\)
110	✅	✅	❌	\(m!\genfrac\{\}{0pt}0nm\)
111	✅	✅	✅	\(m^n\)

克莉丝随笔

通过 Matrix-WeChat 将微信消息转发至 Beeper

概念

准备

配置

bbctl

Matrix WeChat

Matrix WeChat Agent

启动

Matrix 客户端初始化

收尾

莫比乌斯反演

前置知识

偏序关系

卷积

Iverson 括号

Kronecker delta 函数

Zeta 函数

Möbius mu 函数

定义

性质

\((\mathbb N,\le)\)

\((\mathcal P(S),\subseteq)\)

偏序集直积

\((\mathbb N,|)\)

Möbius 反演

容斥原理

二项式反演

数论反演

C++ 用户定义 Ranges 算子

概念

范围 Range

视图 View

范围适配器 Range Adaptor

范围适配器闭包 Range Adaptor Closure

实现

标准库帮助类

成品

在 macOS 上用 Game Porting Toolkit 运行原神崩铁

准备

Game Porting Toolkit 安装

Wine 配置

原神

崩铁

一些问题

更新日志

2023-07-23

2023-08-31

2024-02-15

小球放到盒子里的排列组合问题

整数分拆函数

第二类斯特林数

编号 000：球相同、盒相同、盒非空

编号 001：球相同、盒相同、盒可空

编号 010：球相同、盒不同、盒非空

编号 011：球相同、盒不同、盒可空

编号 100：球不同、盒相同、盒非空

编号 101：球不同、盒相同、盒可空

编号 110：球不同、盒不同、盒非空

编号 111：球不同、盒不同、盒可空

参考资料

GCC 部分内建位运算函数轮子

Counting Trailing Zeros

朴素

二分

IEEE-754 性质

de Bruijn 序列性质（映射查表）

Find First Set

Count Leading Zeros

朴素

二分

IEEE-754 性质

de Bruijn 序列性质（映射查表）

Count Leading Redundant Sign Bits

Population Count

朴素

一个优化

二分

Parity

偷懒