我的正则表达式是别人教会我的和C的模板元编程一样属于那种“每次想起来都觉得脑子不够用但看懂一次就觉得值了”的东西。之前我花了两三个晚上用C的模板写了一个能在编译期解析正则表达式并直接匹配字符串的库今天把整个思路、实现过程、踩过的坑都拉出来聊一聊希望给你一些参考。先说一个很多人会问的问题编译期正则到底有什么用一句话回答就是把“正则表达式的解析和匹配”这个工作从运行时挪到编译期。你写死的那些字符串规则可以在编译时就验证格式是否正确可以让匹配结果成为常量表达式甚至可以用类型系统提前暴露错误。比如你写了一个正则里面语法写错了传统做法是运行时抛异常而编译期实现会让你连编译都过不去。这对一些对运行时开销特别敏感的场景比如嵌入式、游戏引擎的底层工具链、或者那些在启动时要做大量规则加载的程序都是实打实的收益。不过我必须提前打个预防针用模板做编译期正则绝对不是一个轻松的活。它的复杂度比普通正则引擎高不少写模板要像写函数式程序一样思考稍微不小心编译错误信息就能刷屏几十行。但换个角度说一旦你把这个过程走通你对C模板、类型推导、编译期计算的整个理解会上一个台阶。1. 编译期正则的总体设计思路整个实现在我看来可以拆成三个大块把正则表达式字符串在编译期拆分成一个一个的语法单元然后把这些单元组合成一个状态机最后在编译期用这个状态机去匹配输入字符串。这三步对应的其实就是普通正则引擎的“解析”“编译”“执行”三个阶段。关键区别在于我们所有的数据结构和计算过程都不能依赖运行时堆内存一切交给模板和常量表达式。1.1 为什么选择纯模板而不是 constexprC 的 constexpr 在 C14 之后已经非常强大了可以用来写编译器求值的循环、分支、递归函数。那为什么还要用模板呢主要原因有两点。第一constexpr 函数能处理的问题是有限度的如果你想在编译期持有一些动态长度的数据结构比如一个状态链表、一组转移边纯 constexpr 环境下做起来非常别扭。你很难在常量表达式的语境里动态分配内存。第二也是我个人的体会模板元编程能更自然地表达“类型级别的状态机”每一步匹配的结果直接体现在类型上。你用 constexpr 写出来的只能是一块返回 bool 的函数你无法轻易把“当前状态”本身做成一个类型传给下一个递归。当然现在的 C20 和 C23 已经把 constexpr 的能力扩展得很大部分场景下用 constexpr 函数写会简单很多。如果你只是想要“编译期验证正则语法”那 constexpr 的实现完全够用。但如果目标是“正则的语义在编译期参与类型计算”模板这条路线更彻底。我最终采用的方案是两者结合模板负责表达语法树和状态机的类型结构constexpr 函数负责处理那些相对简单的字符判断和数值计算。这样既避免了全模板写法里的极端难读也保住了编译期计算的灵活度。1.2 从正则字符串到语法树正则表达式本身是一个字符串比如 “[a-z][0-9]{2}” 这种。传统的解析做法是逐个字符扫描然后生成一棵语法树。编译期干类似的事只不过“字符串”不是运行时的变量而是一个 constexpr 的字符序列。在 C20 之前最优雅的表达方式是用模板参数包比如templatechar... Cs struct regex_string {};配合一个 constexpr 的“字符序列转类型”的函数就能把 “ab” 这样的字符串字面量在编译期转成regex_stringa,,b。这是整个工程的地基。有了它后续对正则内容的解析就可以用模板特化和递归来处理。用这种字符包展开的方式有个明显的好处就是pattern里的每一个字符都可以直接参与模板匹配。比如我们要识别字符类[...]可以直接写一个专门的特化匹配[开头的包。这种做法相当于把一个解析器写进了类型系统每一步拆解都发生在递归模板的实例化过程中。1.3 语法树到 NFA/DFA 状态机正则表达式和有限自动机的关系是计算机课程里经典的内容。每一条正则规则都可以等价转换为一个非确定有限自动机NFA然后通过子集构造法变成确定有限自动机DFA。但在模板元编程里我不推荐真的去构建一个包含转移表的结构体因为模板实例化深度有限制递归构造NFA再转DFA对编译器来说压力很大。我后来采用了一个简化技巧不需要真正转换成DFA表的形态而是把语法树直接当作“匹配逻辑”来用。每个节点的求值靠递归完成父节点依次尝试子节点的匹配路径。说白了我们用计算代替了查表用模板递归模拟了状态转移。这个做法的好处是代码结构很清晰坏处是匹配的效率比正经的DFA要差一点但它在编译期执行无所谓性能。2. 核心细节解析与实操要点说起来容易做起来难。模板元编程的核心难点在于“递归终止”和“类型聚合”这两个控制流。接下来我挑几个影响全局的决定性细节仔细展开。2.1 用空参包做输入终止标记在运行时的正则匹配里我们每匹配一个字符就把输入指针往后移动一次到字符不匹配时停止。在模板版本里输入字符串也是字符包每匹配掉一个字符就递归地把剩余字符包传给下一个实例化。这里最关键的技巧是终止条件的判断。模板匹配必须能检测到“字符包为空”这个状态。在 C 模板里可以用一个辅助结构体配合特化来解决templatechar... Rest struct matcher; // 特化当前无剩余字符 template struct matcher { static constexpr bool match ...; };配合requires或者一些if constexpr的写法可以把剩余字符包是否为空作为分支条件。C20 之后还可以用requires子句直接约束模板让程序在某些状态下不走匹配分支。这个小技巧看起来基础实际写代码的时候却是整个结构的命门——如果你没处理好空包编译期递归就会无限实例化直接引爆编译器。我自己的习惯是在最外层封装一个match_result的结构里面把“匹配成功与否”“剩余输入”和“是否消耗了字符”三样东西一起打包。这样递归的每一层都能把“结果”和“输入状态”传递给上层避免编写额外的判断代码。2.2 处理重复量词的循环逻辑正则里的量词比如* ? {n,m}在传统引擎里是图上的回路状态。在模板元编程里我把量词理解成一个“递归尝试”的操作。最简单的方式是用“先尝试一次匹配再看后续是否在量词范围内”的贪心策略。我写了一个核心的辅助模板名字叫repeat_matcher它接收三个参数被重复的子表达式、当前已重复次数、剩余输入。它的匹配逻辑是先用子表达式试着匹配一次如果成功了就递归调用自己重复次数加一如果失败就检查当前次数是否满足量词的下限要求。这里有个重要的“坑”就是正则的贪婪匹配和回溯。运行时引擎可以保存多个状态然后失败时回退。但在编译期模拟回溯非常消耗模板实例化的数量因为每一层递归都可能展开出多个分支实例化爆炸会导致编译变慢或直接超时。解决这个问题的办法是我在写这个项目时学到的最有价值的东西之一针对性简化贪婪匹配。我改成了“没有回溯”的匹配。只要量词的上限没到就尽力匹配一旦失败就立即终止不再回退寻找其它的可能路径。这确实会丢失一些正则本应有的“最优匹配”能力但对大多数实际应用场景已经足够了。如果你真的需要完整回溯那么你就要准备接受极长的编译时间。2.3 字符类和转义字符的展开字符类[a-z]和预定义类\d \w \s的内容等价于一个字符集合的判断。在模板里我将这类判断都用 constexpr 函数实现。这里不用模板特化直接写一个普通的 constexpr 函数每次求值即可节省了不少模板实例化。一个很容易被忽略的细节是转义。正则表达式在字符串字面量里本身就有一层转义在模板字符包中又有一层。比如你写\d在 C 字符串里要写\\d在传给模板后实际上得到的是两个字符\\和d。所以编译器在处理字符包时需要先识别出“反斜杠字母”这个组合再将它们合并成一个语义单元。我设计了一个parse_escape类专门处理字符包中的转义序列。它把反斜杠和后面的字符一起消费掉同时输出一个代表字符类别的常量。对于\n \t这类控制字符直接映射为ASCII码。对于\d \w这类预定义类映射为对应的字符集合判断函数编号。2.4 编译期异常处理编译期正则一个非常吸引人的特性就是可以“编译期报错”。如果你写的正则语法本身就错了比如(a[b]这种括号没闭合的正常运行时解析器会抛异常。但编译期版本可以直接打印static_assert错误信息让你在编译器输出里就看到“正则表达式括号不匹配”这样的提示。核心实现方式就是在前面的解析模板中为每一个可能的语法错误加一个专门的特化分支。当这个分支被触发时就触发一个static_assert并且把错误码放在断言消息里。值得强调的是你构造的报错信息一定要跟代码中的位置关联起来否则排查起来非常痛苦。我后来在自己的代码里把#line指令也用上了这样错误信息直接跳转到正则字符串被定义的那一行。3. 实操过程与核心环节实现下面直接给出核心代码结构。我以匹配一个简化版本的“IPv4地址”为例演示这个库的用法。它的实现思路可以扩展到任意你需要的正则规则。这个例子的目的不是要给你看完整源码而是把一个实际模板函数从写法到思路梳理清楚。3.1 如何定义编译期正则对象我们需要一个封装好的宏来简化调用。我用了一个辅助结构体把字符串转换成字符包templatesize_t N constexpr auto make_regex(const char (str)[N]) { return regex_from_charsstr_char_seq(str)...{}; }这里str_char_seq(str)是一个 constexpr 辅助函数作用是提取出字符串里除了末尾\0之外的每一个字符。宏层面可以简化成#define REGEX(pattern) decltype(make_regex(pattern))使用的时候你写REGEX([0-9]\\.[0-9])得到的类型就是一个已经解析好语法树的模板类型。3.2 匹配器的完整骨架整个匹配器我设计成一个统一入口的模板结构模式如下templatetypename Regex, char... Input struct regex_matcher { static constexpr bool value Regex::matchInput...::result; };Regex::match是核心。在语法树内部每个节点都提供一个静态成员函数matchInput...()返回一个match_stateInput...。这样设计的好处是每个节点是自包含的组合起来也很自然。比如连接操作ab就相当于先跑a的匹配然后把剩余输入交给b。因为整个过程都在类型抹消的编译期进行我们不需要真正返回一个字符串只需要把剩余的字符包作为模板参数继续传递就可以。3.3 一个实际例子匹配数字或用逗号分隔的列表挑一个更容易理解的目标匹配“用逗号分隔的一个或多个数字”像12,34,56这样的输入。我先定义一个代表数字的编译期正则REGEX([0-9])。然后定义一个代表逗号的字面量REGEX(,)。最后用连接操作把两者组合起来。由于我的库并不打算在模板里完整实现正则语法解析到 NFA 的全部流程所以我直接给最核心的组合逻辑代码。这样的设计也让整个库天然地支持后续扩展——只要你想让新的语法单元参与匹配就多写一个对应的模板特化即可。实际写代码时我发现一个经验值得分享与其花大力气把通用正则的全部语法都实现了不如先针对你的常用规则封装好几个基础组合子例如literal、sequence、alternative、repeat、charset。然后需要新规则的时候直接从这几个基础组合子出发拼接。这样实现的编译期正则既不臃肿而且编译速度也快得多。3.4 对 constexpr 版本的取舍如果你觉得模板版本的嵌套结构太复杂推荐一个折中方案用constexpr函数做编译期语法检查然后仍然用传统的运行时正则引擎做最终匹配。比如你可以编写一个constexpr bool validate_pattern(const char* str)函数在代码里用static_assert(validate_pattern(...))来提前拦截语法错误。这种方案兼容性更好代码也更短。现在以 C20 的std::vector为例它支持 constexpr 但并非所有操作都可以在编译期求值所以我还是坚持用纯模板方案处理核心的状态机。纯模板虽然难懂但它有一种“确定感”。你写的模板代码行为是编译器直接展开的不依赖运行时的堆分配不会存在“常量表达式求值踩了动态分配限制”的暗坑。4. 常见问题与排查技巧实录编译期正则这种工作调试起来跟普通代码完全是两个世界。程序崩溃了你可以用 gdb 调试模板实例化出错了你只能面对那一坨编译错误。下面把最容易踩的坑列出来。4.1 模板递归实例化深度超限这个是最早遇到、也是最经典的问题。如果你在写一个处理长字符串的正则并且递归模式分支比较深编译器会报template instantiation depth exceeds maximum之类错误。解决办法有两个方向。第一提高编译器的模板实例化深度上限比如在 GCC 下面用-ftemplate-depth1000增加上限。但这只是治标深层递归依然会让编译速度缓慢到难以忍受。第二重构代码减少递归层数。例如把一次匹配中“需要连续调用 N 次递归”的逻辑改成“在一个 constexpr 循环里尽可能完成”。我后来针对大输入场景做的优化就是在 constexpr 和模板之间做切换让循环部分不再消耗模板实例化深度。4.2 匹配结果的分支爆炸当正则里头出现多个|选项时模板会展开选择的多个分支。比如a|b|c|d这种选项写成递归模板就会产生多个平行实例化。如果选项再叠加重复量词那编译器要展开的模板数量往往是几何级的。实际工程里看到的就是编译几十分钟甚至内存耗尽。我的处理方式是“限制并行分支数”。语法树节点里存储的不再是一个个独立的模板分支而是把字符判断压缩成一张常量表在运行时配合if constexpr去筛选。这可以理解为把一部分运行时信息又重新引了回来但在编译期不太敏感的场景下这是值得的。4.3 如何快速定位模板错误模板错误信息通常杂乱无章。我自己的排查流程很简单先注释掉所有无关的匹配模板一次只保留一个最简单的情况。例如先只匹配一个空字符串、一个字符失败了就在最小用例下观察错误。然后把错误信息里第一个明确的“required from here”标签附近的代码行拿出来单独看基本能定位到递归卡住的地方。另一个技巧值得大力推荐用static_assert输出中间类型信息。虽然 C 的世界里没有 println但你可以用static_assert(sizeof(某个类型) 0)来强制报错并把这个类型的名字带进错误信息里。看着有点土实际排查模板问题时比什么都好用。4.4 在编译错误里显示正则原始内容我在开发过程中有过一次特别痛苦的经历——某个正则写错了但错误提示里只显示一堆regex_string1,9,2,.,1,6,8我看半天都没意识到是哪里错了。后来我给regex_string增加了一个静态成员函数pretty_name()借助编译器 RTTI 或者依赖__PRETTY_FUNCTION__的输出把字符重新拼成可读字符串。这样静态断言里能直接输出原始的正则样式排查速度快了一倍都不止。原理很简单__PRETTY_FUNCTION__在编译期就包含了模板参数的完整描述我们只需要把这个名字剥出来再把那些数字字符转换成对应的可见字符。5. 工具选型与编译器兼容性写模板元编程最痛苦的还不是代码本身而是不同编译器之间的行为差异。别人用 GCC 能编译通过的代码拿到 MSVC 上可能就是另一番光景。这里分享一份我实测之后得到的经验。5.1 不同编译器的表现对比GCC强项是模板实例化深度上限比较高对模板元编程支持成熟出错的提示虽然长但信息相对全。建议开发期一直用 GCC。Clang在模板诊断上普遍口碑最好错误信息排版清晰同时还支持自定义约束的信息提示。如果是新手尝试这种玩具项目Clang 是最友好的。MSVC对传统模板的支持也不错但在某些 constexpr 和模板交互的边缘场景下行为刁钻。比如我在 MSVC 上遇到过一个字符包匹配时的特化顺序问题同一段代码在 GCC 下能匹配在 MSVC 下就是编译失败。遇到这种问题别死磕用#ifdef区分编译器选择不同的实现路径。5.2 VSCode 环境配置要点如果你是在 VSCode 里写 C 模板强烈建议安装 C 插件并把cppStandard设置成c20或更高。模板元编程通常要大量查看__PRETTY_FUNCTION__输出而 VSCode 的智能感知对这种高级特性支持参差不齐。建议在命令行里用 g 编译生成错误信息后再回到编辑器修复。在 VSCode 里看模板递归超级长的时候也要学会折叠template关键字整段的代码区域否则编辑器会很卡。这些配置本身不复杂但能明显改善模板工程的调试体验。如果你经常做这类模板实验我个人的经验是不要在 IDE 的“自动解析错误”上浪费太多时间。C 的模板元编程错误信息依赖完整的编译上下文而 IDE 的实时分析一堆时候是会漏报误报的。宁可命令行长编译一次也别等 IDE 的提示。5.3 是否需要运行时正则库作为兜底编译期正则再强也只能处理“模式是编译期常量”的场景。一旦模式来自用户输入或者配置文件运行时读取就必须回到传统的运行时正则引擎。我个人项目里的处理方式是做一个编译期选择模式是字符串字面量时优先用编译期实现模式是非常量时自动退化到std::regex。这样兼顾了效率和灵活性。有一个细节在于std::regex和编译期库的匹配语义并不是完全一致的。比如std::regex默认支持 ECMAScript 语法而我的编译期简化版只支持一个子集。所以在同一份代码里混用两者时要仔细核对边界情况避免“编译期验证通过运行时正则不认”这种乌龙。6. 扩展思路与个人经验总结做一个编译期正则最痛但我认为最值得的收获是深入体会了“把复杂逻辑放进类型系统”的思考方式。你坐在编辑器里写的每一个模板结构都在编译那一刹那就变成了具体的代码展开。这个思维转变一旦形成后面再去看std::variant、std::visit或者任意泛型库的实现都会通透得多。如果你有精力继续扩展下面几条路线给你参考。第一支持更多语法糖比如非捕获组、懒惰匹配、反向引用。第二个说难也不难把解析出的语法树序列化成编译期常量这样你就可以把这个语法树直接dump成运行时 DFA 的字节码。第三配合std::string_view让编译期匹配的输入直接从字符串字面量推进到 string_view 常量。这些扩展方向都需要对现有模板结构做一些调整但不是伤筋动骨的改动。最后再分享一个我个人的小技巧。写这种大型模板库的时候别急着一口气写完所有功能。先把最简单的字符串字面量匹配跑通然后加|选择符然后加*重复每加一个功能就编一次把能通过的测试都留着。加新功能时如果编译挂了优先怀疑是新增的模板特化发生了路径冲突。这种增量开发的方式虽然看起来慢但实际调试效率比一次性堆一个大而全的库高出好几条街。碰过了这份苦以后转回头说你最初的疑问“C编译期正则表达式有价值吗”我的看法是它未必能替代运行时正则库但它本身是一次极佳的训练场。它会逼你把算法和类型推导焊在一起逼你学会在编译器的错误信息里寻找线索。这一套能力放在任何C项目里都是相当值钱的经验。
C++编译期正则表达式：模板元编程与constexpr实战解析
我的正则表达式是别人教会我的和C的模板元编程一样属于那种“每次想起来都觉得脑子不够用但看懂一次就觉得值了”的东西。之前我花了两三个晚上用C的模板写了一个能在编译期解析正则表达式并直接匹配字符串的库今天把整个思路、实现过程、踩过的坑都拉出来聊一聊希望给你一些参考。先说一个很多人会问的问题编译期正则到底有什么用一句话回答就是把“正则表达式的解析和匹配”这个工作从运行时挪到编译期。你写死的那些字符串规则可以在编译时就验证格式是否正确可以让匹配结果成为常量表达式甚至可以用类型系统提前暴露错误。比如你写了一个正则里面语法写错了传统做法是运行时抛异常而编译期实现会让你连编译都过不去。这对一些对运行时开销特别敏感的场景比如嵌入式、游戏引擎的底层工具链、或者那些在启动时要做大量规则加载的程序都是实打实的收益。不过我必须提前打个预防针用模板做编译期正则绝对不是一个轻松的活。它的复杂度比普通正则引擎高不少写模板要像写函数式程序一样思考稍微不小心编译错误信息就能刷屏几十行。但换个角度说一旦你把这个过程走通你对C模板、类型推导、编译期计算的整个理解会上一个台阶。1. 编译期正则的总体设计思路整个实现在我看来可以拆成三个大块把正则表达式字符串在编译期拆分成一个一个的语法单元然后把这些单元组合成一个状态机最后在编译期用这个状态机去匹配输入字符串。这三步对应的其实就是普通正则引擎的“解析”“编译”“执行”三个阶段。关键区别在于我们所有的数据结构和计算过程都不能依赖运行时堆内存一切交给模板和常量表达式。1.1 为什么选择纯模板而不是 constexprC 的 constexpr 在 C14 之后已经非常强大了可以用来写编译器求值的循环、分支、递归函数。那为什么还要用模板呢主要原因有两点。第一constexpr 函数能处理的问题是有限度的如果你想在编译期持有一些动态长度的数据结构比如一个状态链表、一组转移边纯 constexpr 环境下做起来非常别扭。你很难在常量表达式的语境里动态分配内存。第二也是我个人的体会模板元编程能更自然地表达“类型级别的状态机”每一步匹配的结果直接体现在类型上。你用 constexpr 写出来的只能是一块返回 bool 的函数你无法轻易把“当前状态”本身做成一个类型传给下一个递归。当然现在的 C20 和 C23 已经把 constexpr 的能力扩展得很大部分场景下用 constexpr 函数写会简单很多。如果你只是想要“编译期验证正则语法”那 constexpr 的实现完全够用。但如果目标是“正则的语义在编译期参与类型计算”模板这条路线更彻底。我最终采用的方案是两者结合模板负责表达语法树和状态机的类型结构constexpr 函数负责处理那些相对简单的字符判断和数值计算。这样既避免了全模板写法里的极端难读也保住了编译期计算的灵活度。1.2 从正则字符串到语法树正则表达式本身是一个字符串比如 “[a-z][0-9]{2}” 这种。传统的解析做法是逐个字符扫描然后生成一棵语法树。编译期干类似的事只不过“字符串”不是运行时的变量而是一个 constexpr 的字符序列。在 C20 之前最优雅的表达方式是用模板参数包比如templatechar... Cs struct regex_string {};配合一个 constexpr 的“字符序列转类型”的函数就能把 “ab” 这样的字符串字面量在编译期转成regex_stringa,,b。这是整个工程的地基。有了它后续对正则内容的解析就可以用模板特化和递归来处理。用这种字符包展开的方式有个明显的好处就是pattern里的每一个字符都可以直接参与模板匹配。比如我们要识别字符类[...]可以直接写一个专门的特化匹配[开头的包。这种做法相当于把一个解析器写进了类型系统每一步拆解都发生在递归模板的实例化过程中。1.3 语法树到 NFA/DFA 状态机正则表达式和有限自动机的关系是计算机课程里经典的内容。每一条正则规则都可以等价转换为一个非确定有限自动机NFA然后通过子集构造法变成确定有限自动机DFA。但在模板元编程里我不推荐真的去构建一个包含转移表的结构体因为模板实例化深度有限制递归构造NFA再转DFA对编译器来说压力很大。我后来采用了一个简化技巧不需要真正转换成DFA表的形态而是把语法树直接当作“匹配逻辑”来用。每个节点的求值靠递归完成父节点依次尝试子节点的匹配路径。说白了我们用计算代替了查表用模板递归模拟了状态转移。这个做法的好处是代码结构很清晰坏处是匹配的效率比正经的DFA要差一点但它在编译期执行无所谓性能。2. 核心细节解析与实操要点说起来容易做起来难。模板元编程的核心难点在于“递归终止”和“类型聚合”这两个控制流。接下来我挑几个影响全局的决定性细节仔细展开。2.1 用空参包做输入终止标记在运行时的正则匹配里我们每匹配一个字符就把输入指针往后移动一次到字符不匹配时停止。在模板版本里输入字符串也是字符包每匹配掉一个字符就递归地把剩余字符包传给下一个实例化。这里最关键的技巧是终止条件的判断。模板匹配必须能检测到“字符包为空”这个状态。在 C 模板里可以用一个辅助结构体配合特化来解决templatechar... Rest struct matcher; // 特化当前无剩余字符 template struct matcher { static constexpr bool match ...; };配合requires或者一些if constexpr的写法可以把剩余字符包是否为空作为分支条件。C20 之后还可以用requires子句直接约束模板让程序在某些状态下不走匹配分支。这个小技巧看起来基础实际写代码的时候却是整个结构的命门——如果你没处理好空包编译期递归就会无限实例化直接引爆编译器。我自己的习惯是在最外层封装一个match_result的结构里面把“匹配成功与否”“剩余输入”和“是否消耗了字符”三样东西一起打包。这样递归的每一层都能把“结果”和“输入状态”传递给上层避免编写额外的判断代码。2.2 处理重复量词的循环逻辑正则里的量词比如* ? {n,m}在传统引擎里是图上的回路状态。在模板元编程里我把量词理解成一个“递归尝试”的操作。最简单的方式是用“先尝试一次匹配再看后续是否在量词范围内”的贪心策略。我写了一个核心的辅助模板名字叫repeat_matcher它接收三个参数被重复的子表达式、当前已重复次数、剩余输入。它的匹配逻辑是先用子表达式试着匹配一次如果成功了就递归调用自己重复次数加一如果失败就检查当前次数是否满足量词的下限要求。这里有个重要的“坑”就是正则的贪婪匹配和回溯。运行时引擎可以保存多个状态然后失败时回退。但在编译期模拟回溯非常消耗模板实例化的数量因为每一层递归都可能展开出多个分支实例化爆炸会导致编译变慢或直接超时。解决这个问题的办法是我在写这个项目时学到的最有价值的东西之一针对性简化贪婪匹配。我改成了“没有回溯”的匹配。只要量词的上限没到就尽力匹配一旦失败就立即终止不再回退寻找其它的可能路径。这确实会丢失一些正则本应有的“最优匹配”能力但对大多数实际应用场景已经足够了。如果你真的需要完整回溯那么你就要准备接受极长的编译时间。2.3 字符类和转义字符的展开字符类[a-z]和预定义类\d \w \s的内容等价于一个字符集合的判断。在模板里我将这类判断都用 constexpr 函数实现。这里不用模板特化直接写一个普通的 constexpr 函数每次求值即可节省了不少模板实例化。一个很容易被忽略的细节是转义。正则表达式在字符串字面量里本身就有一层转义在模板字符包中又有一层。比如你写\d在 C 字符串里要写\\d在传给模板后实际上得到的是两个字符\\和d。所以编译器在处理字符包时需要先识别出“反斜杠字母”这个组合再将它们合并成一个语义单元。我设计了一个parse_escape类专门处理字符包中的转义序列。它把反斜杠和后面的字符一起消费掉同时输出一个代表字符类别的常量。对于\n \t这类控制字符直接映射为ASCII码。对于\d \w这类预定义类映射为对应的字符集合判断函数编号。2.4 编译期异常处理编译期正则一个非常吸引人的特性就是可以“编译期报错”。如果你写的正则语法本身就错了比如(a[b]这种括号没闭合的正常运行时解析器会抛异常。但编译期版本可以直接打印static_assert错误信息让你在编译器输出里就看到“正则表达式括号不匹配”这样的提示。核心实现方式就是在前面的解析模板中为每一个可能的语法错误加一个专门的特化分支。当这个分支被触发时就触发一个static_assert并且把错误码放在断言消息里。值得强调的是你构造的报错信息一定要跟代码中的位置关联起来否则排查起来非常痛苦。我后来在自己的代码里把#line指令也用上了这样错误信息直接跳转到正则字符串被定义的那一行。3. 实操过程与核心环节实现下面直接给出核心代码结构。我以匹配一个简化版本的“IPv4地址”为例演示这个库的用法。它的实现思路可以扩展到任意你需要的正则规则。这个例子的目的不是要给你看完整源码而是把一个实际模板函数从写法到思路梳理清楚。3.1 如何定义编译期正则对象我们需要一个封装好的宏来简化调用。我用了一个辅助结构体把字符串转换成字符包templatesize_t N constexpr auto make_regex(const char (str)[N]) { return regex_from_charsstr_char_seq(str)...{}; }这里str_char_seq(str)是一个 constexpr 辅助函数作用是提取出字符串里除了末尾\0之外的每一个字符。宏层面可以简化成#define REGEX(pattern) decltype(make_regex(pattern))使用的时候你写REGEX([0-9]\\.[0-9])得到的类型就是一个已经解析好语法树的模板类型。3.2 匹配器的完整骨架整个匹配器我设计成一个统一入口的模板结构模式如下templatetypename Regex, char... Input struct regex_matcher { static constexpr bool value Regex::matchInput...::result; };Regex::match是核心。在语法树内部每个节点都提供一个静态成员函数matchInput...()返回一个match_stateInput...。这样设计的好处是每个节点是自包含的组合起来也很自然。比如连接操作ab就相当于先跑a的匹配然后把剩余输入交给b。因为整个过程都在类型抹消的编译期进行我们不需要真正返回一个字符串只需要把剩余的字符包作为模板参数继续传递就可以。3.3 一个实际例子匹配数字或用逗号分隔的列表挑一个更容易理解的目标匹配“用逗号分隔的一个或多个数字”像12,34,56这样的输入。我先定义一个代表数字的编译期正则REGEX([0-9])。然后定义一个代表逗号的字面量REGEX(,)。最后用连接操作把两者组合起来。由于我的库并不打算在模板里完整实现正则语法解析到 NFA 的全部流程所以我直接给最核心的组合逻辑代码。这样的设计也让整个库天然地支持后续扩展——只要你想让新的语法单元参与匹配就多写一个对应的模板特化即可。实际写代码时我发现一个经验值得分享与其花大力气把通用正则的全部语法都实现了不如先针对你的常用规则封装好几个基础组合子例如literal、sequence、alternative、repeat、charset。然后需要新规则的时候直接从这几个基础组合子出发拼接。这样实现的编译期正则既不臃肿而且编译速度也快得多。3.4 对 constexpr 版本的取舍如果你觉得模板版本的嵌套结构太复杂推荐一个折中方案用constexpr函数做编译期语法检查然后仍然用传统的运行时正则引擎做最终匹配。比如你可以编写一个constexpr bool validate_pattern(const char* str)函数在代码里用static_assert(validate_pattern(...))来提前拦截语法错误。这种方案兼容性更好代码也更短。现在以 C20 的std::vector为例它支持 constexpr 但并非所有操作都可以在编译期求值所以我还是坚持用纯模板方案处理核心的状态机。纯模板虽然难懂但它有一种“确定感”。你写的模板代码行为是编译器直接展开的不依赖运行时的堆分配不会存在“常量表达式求值踩了动态分配限制”的暗坑。4. 常见问题与排查技巧实录编译期正则这种工作调试起来跟普通代码完全是两个世界。程序崩溃了你可以用 gdb 调试模板实例化出错了你只能面对那一坨编译错误。下面把最容易踩的坑列出来。4.1 模板递归实例化深度超限这个是最早遇到、也是最经典的问题。如果你在写一个处理长字符串的正则并且递归模式分支比较深编译器会报template instantiation depth exceeds maximum之类错误。解决办法有两个方向。第一提高编译器的模板实例化深度上限比如在 GCC 下面用-ftemplate-depth1000增加上限。但这只是治标深层递归依然会让编译速度缓慢到难以忍受。第二重构代码减少递归层数。例如把一次匹配中“需要连续调用 N 次递归”的逻辑改成“在一个 constexpr 循环里尽可能完成”。我后来针对大输入场景做的优化就是在 constexpr 和模板之间做切换让循环部分不再消耗模板实例化深度。4.2 匹配结果的分支爆炸当正则里头出现多个|选项时模板会展开选择的多个分支。比如a|b|c|d这种选项写成递归模板就会产生多个平行实例化。如果选项再叠加重复量词那编译器要展开的模板数量往往是几何级的。实际工程里看到的就是编译几十分钟甚至内存耗尽。我的处理方式是“限制并行分支数”。语法树节点里存储的不再是一个个独立的模板分支而是把字符判断压缩成一张常量表在运行时配合if constexpr去筛选。这可以理解为把一部分运行时信息又重新引了回来但在编译期不太敏感的场景下这是值得的。4.3 如何快速定位模板错误模板错误信息通常杂乱无章。我自己的排查流程很简单先注释掉所有无关的匹配模板一次只保留一个最简单的情况。例如先只匹配一个空字符串、一个字符失败了就在最小用例下观察错误。然后把错误信息里第一个明确的“required from here”标签附近的代码行拿出来单独看基本能定位到递归卡住的地方。另一个技巧值得大力推荐用static_assert输出中间类型信息。虽然 C 的世界里没有 println但你可以用static_assert(sizeof(某个类型) 0)来强制报错并把这个类型的名字带进错误信息里。看着有点土实际排查模板问题时比什么都好用。4.4 在编译错误里显示正则原始内容我在开发过程中有过一次特别痛苦的经历——某个正则写错了但错误提示里只显示一堆regex_string1,9,2,.,1,6,8我看半天都没意识到是哪里错了。后来我给regex_string增加了一个静态成员函数pretty_name()借助编译器 RTTI 或者依赖__PRETTY_FUNCTION__的输出把字符重新拼成可读字符串。这样静态断言里能直接输出原始的正则样式排查速度快了一倍都不止。原理很简单__PRETTY_FUNCTION__在编译期就包含了模板参数的完整描述我们只需要把这个名字剥出来再把那些数字字符转换成对应的可见字符。5. 工具选型与编译器兼容性写模板元编程最痛苦的还不是代码本身而是不同编译器之间的行为差异。别人用 GCC 能编译通过的代码拿到 MSVC 上可能就是另一番光景。这里分享一份我实测之后得到的经验。5.1 不同编译器的表现对比GCC强项是模板实例化深度上限比较高对模板元编程支持成熟出错的提示虽然长但信息相对全。建议开发期一直用 GCC。Clang在模板诊断上普遍口碑最好错误信息排版清晰同时还支持自定义约束的信息提示。如果是新手尝试这种玩具项目Clang 是最友好的。MSVC对传统模板的支持也不错但在某些 constexpr 和模板交互的边缘场景下行为刁钻。比如我在 MSVC 上遇到过一个字符包匹配时的特化顺序问题同一段代码在 GCC 下能匹配在 MSVC 下就是编译失败。遇到这种问题别死磕用#ifdef区分编译器选择不同的实现路径。5.2 VSCode 环境配置要点如果你是在 VSCode 里写 C 模板强烈建议安装 C 插件并把cppStandard设置成c20或更高。模板元编程通常要大量查看__PRETTY_FUNCTION__输出而 VSCode 的智能感知对这种高级特性支持参差不齐。建议在命令行里用 g 编译生成错误信息后再回到编辑器修复。在 VSCode 里看模板递归超级长的时候也要学会折叠template关键字整段的代码区域否则编辑器会很卡。这些配置本身不复杂但能明显改善模板工程的调试体验。如果你经常做这类模板实验我个人的经验是不要在 IDE 的“自动解析错误”上浪费太多时间。C 的模板元编程错误信息依赖完整的编译上下文而 IDE 的实时分析一堆时候是会漏报误报的。宁可命令行长编译一次也别等 IDE 的提示。5.3 是否需要运行时正则库作为兜底编译期正则再强也只能处理“模式是编译期常量”的场景。一旦模式来自用户输入或者配置文件运行时读取就必须回到传统的运行时正则引擎。我个人项目里的处理方式是做一个编译期选择模式是字符串字面量时优先用编译期实现模式是非常量时自动退化到std::regex。这样兼顾了效率和灵活性。有一个细节在于std::regex和编译期库的匹配语义并不是完全一致的。比如std::regex默认支持 ECMAScript 语法而我的编译期简化版只支持一个子集。所以在同一份代码里混用两者时要仔细核对边界情况避免“编译期验证通过运行时正则不认”这种乌龙。6. 扩展思路与个人经验总结做一个编译期正则最痛但我认为最值得的收获是深入体会了“把复杂逻辑放进类型系统”的思考方式。你坐在编辑器里写的每一个模板结构都在编译那一刹那就变成了具体的代码展开。这个思维转变一旦形成后面再去看std::variant、std::visit或者任意泛型库的实现都会通透得多。如果你有精力继续扩展下面几条路线给你参考。第一支持更多语法糖比如非捕获组、懒惰匹配、反向引用。第二个说难也不难把解析出的语法树序列化成编译期常量这样你就可以把这个语法树直接dump成运行时 DFA 的字节码。第三配合std::string_view让编译期匹配的输入直接从字符串字面量推进到 string_view 常量。这些扩展方向都需要对现有模板结构做一些调整但不是伤筋动骨的改动。最后再分享一个我个人的小技巧。写这种大型模板库的时候别急着一口气写完所有功能。先把最简单的字符串字面量匹配跑通然后加|选择符然后加*重复每加一个功能就编一次把能通过的测试都留着。加新功能时如果编译挂了优先怀疑是新增的模板特化发生了路径冲突。这种增量开发的方式虽然看起来慢但实际调试效率比一次性堆一个大而全的库高出好几条街。碰过了这份苦以后转回头说你最初的疑问“C编译期正则表达式有价值吗”我的看法是它未必能替代运行时正则库但它本身是一次极佳的训练场。它会逼你把算法和类型推导焊在一起逼你学会在编译器的错误信息里寻找线索。这一套能力放在任何C项目里都是相当值钱的经验。
