编译期正则表达式：从零开始

正则表达式，大家都不陌生。字符串匹配、数据提取、格式校验……几乎每个项目里都能见到它的身影。但今天我们要聊的，是在编译期完成这些工作——没错，就是在程序运行之前，把正则匹配的逻辑全部搞定。

我第一次接触这个想法，是在一个嵌入式项目里。设备资源极其有限，运行时正则库根本塞不进去。我当时就想：能不能在编译期就把匹配结果算出来？后来发现，C++模板元编程还真能办到这件事。

基本原理：编译期匹配的核心思想

说白了，编译期正则表达式就是用类型系统来表达模式，用模板递归来模拟状态机。你想想看，正则匹配本质上是一个有限状态自动机（NFA或DFA）在字符串上的遍历过程。而模板元编程最擅长的，恰恰就是这种递归展开和类型计算。

核心思路分三步：

  1. 把正则表达式“编码”成类型——每个字符、每个元字符都对应一个类型
  2. 把待匹配字符串也“编码”成类型——字符序列变成类型列表
  3. 用模板递归模拟状态转移——每一步匹配一个字符，决定下一步走向

关键洞察：编译期正则匹配的本质，是类型层面的模式匹配。运行时是数据驱动，编译期是类型驱动。

简单匹配器的实现思路

我们先从最简单的场景入手：匹配一个固定字符串。比如，判断输入是否等于"abc"。

第一步：定义字符和字符串的类型表示

// 单个字符
template <char C>
struct Char {
    static constexpr char value = C;
};

// 字符串：变长模板参数列表
template <char... Chars>
struct Str {};

// 举个例子："abc" 表示为 Str<'a', 'b', 'c'>

嗯，这里要注意：我们不是在运行时存字符串，而是在类型层面把每个字符“刻”进去。

第二步：定义匹配器的核心模板

// 前置声明
template <typename Pattern, typename Input>
struct Match;

// 特化：空模式匹配空输入 → 成功
template <>
struct Match<Str<>, Str<>> {
    static constexpr bool value = true;
};

// 特化：空模式匹配非空输入 → 失败
template <char... InputChars>
struct Match<Str<>, Str<InputChars...>> {
    static constexpr bool value = false;
};

// 特化：非空模式匹配空输入 → 失败
template <char... PatternChars>
struct Match<Str<PatternChars...>, Str<>> {
    static constexpr bool value = false;
};

// 核心递归：逐个字符比较
template <char P, char... PRest, char I, char... IRest>
struct Match<Str<P, PRest...>, Str<I, IRest...>> {
    static constexpr bool value = 
        (P == I) && Match<Str<PRest...>, Str<IRest...>>::value;
};

个人习惯：我写这种递归模板时，一定会先处理边界条件（空模式、空输入）。否则编译期递归会无限展开，编译器直接报错。我曾经在这上面栽过跟头——一个看似简单的特化遗漏，让编译时间从3秒飙到3分钟。

第三步：使用示例

// 匹配 "abc" 和 "abc"
constexpr bool r1 = Match<Str<'a','b','c'>, Str<'a','b','c'>>::value;
// r1 = true

// 匹配 "abc" 和 "abd"
constexpr bool r2 = Match<Str<'a','b','c'>, Str<'a','b','d'>>::value;
// r2 = false

// 匹配 "abc" 和 "ab"
constexpr bool r3 = Match<Str<'a','b','c'>, Str<'a','b'>>::value;
// r3 = false

你看，逻辑其实很简单——就是逐字符比较，一旦发现不匹配就返回false。但正是这个基础，可以扩展出更复杂的模式。

知识体系结构图

下面这张图，帮你理清编译期正则表达式的整体脉络：

编译期正则表达式知识体系 核心思想：类型即模式，递归即匹配 ① 正则 → 类型编码 ② 输入 → 类型列表 ③ 模板递归模拟状态机 Char<C> / Str<Chars...> 每个字符对应一个类型 Match<P, I> 核心匹配模板 特化处理边界条件 空模式 / 空输入 / 字符不匹配 编译期常量：true / false

扩展思路：从固定字符串到模式匹配

上面只是最基础的固定字符串匹配。实际的正则表达式要复杂得多——通配符、字符集、重复、分组……但万变不离其宗，核心机制是一样的：

正则特性 编译期实现思路 关键模板
通配符 . 匹配任意单个字符 MatchAny
字符集 [abc] 编译期生成字符查找表 CharSet<'a','b','c'>
重复 * 递归展开：匹配0次或多次 Repeat<Pattern>
重复 + 至少匹配1次，再递归匹配0次或多次 AtLeastOne<Pattern>
可选 ? 分支选择：匹配0次或1次 Optional<Pattern>
分组 () 将子模式封装为独立类型 Group<Pattern>

注意：编译期正则表达式有一个天然限制——不支持回溯。因为模板递归一旦展开，路径就固定了。所以像 (a|ab)*c 这种需要回溯的模式，在纯编译期实现起来非常困难。我建议：如果模式复杂度超过“确定有限自动机（DFA）”的范畴，还是用运行时库吧。

一个更完整的例子：支持通配符

我们来扩展一下，让匹配器支持 . 通配符（匹配任意单个字符）：

// 通配符类型
struct Wildcard {};

// 修改 Match 模板，增加通配符处理
template <typename Pattern, typename Input>
struct Match;

// 通配符匹配任意字符
template <char... PRest, char I, char... IRest>
struct Match<Str<Wildcard, PRest...>, Str<I, IRest...>> {
    static constexpr bool value = 
        Match<Str<PRest...>, Str<IRest...>>::value;
};

// 使用示例：匹配 "a.c" 和 "abc"
constexpr bool r4 = Match<Str<'a', Wildcard, 'c'>, Str<'a','b','c'>>::value;
// r4 = true

// 匹配 "a.c" 和 "aXc"
constexpr bool r5 = Match<Str<'a', Wildcard, 'c'>, Str<'a','X','c'>>::value;
// r5 = true

// 匹配 "a.c" 和 "ac"（长度不够）
constexpr bool r6 = Match<Str<'a', Wildcard, 'c'>, Str<'a','c'>>::value;
// r6 = false

你看，加一个通配符支持，只需要新增一个特化模板。这就是模板元编程的魅力——每个特性都是独立的“砖块”，可以灵活组合。

避坑指南

我在实际项目中踩过几个坑，分享给你：

  • 编译时间爆炸：递归深度太大时，编译器会吃不消。我建议把递归深度控制在200层以内，超过这个数就考虑换思路。
  • 错误信息难以阅读：模板匹配失败时，编译器会吐出一大堆类型信息。我的经验是：用 static_assert 加有意义的错误提示，能省很多调试时间。
  • 不要追求“万能”：编译期正则适合模式固定、输入有限的场景。如果模式本身是运行时动态生成的，那还是老老实实用 std::regex 吧。

我的建议：编译期正则表达式最适合用在配置校验、协议解析、固定格式匹配这些场景。比如，检查一个字符串是不是合法的IPv4地址格式——这种模式固定、调用频繁的任务，编译期匹配几乎是零开销。

好了，这一章我们打下了基础。从最简单的固定字符串匹配开始，到支持通配符，再到理解整个知识体系的结构。下一章，我们会深入字符集和重复匹配的实现，让我们的匹配器真正“活”起来。

公众号:蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →