如何使用CTRE匹配指定日期格式的正则表达式？

问题背景 #

现有用于匹配特定日期格式的正则表达式：

(?<weekday>\w{3}),\s+(?<day>\d{1,2})\s+(?<month>\w{3})\s+(?<year>\d{4})\s+(?<hours>\d{2}):(?<minutes>\d{2}):(?<seconds>\d{2})\s+(?<timezone_offset>[+\-]\d{4})(?:\s+\((?<timezone_name>\w+)\))?

目标是匹配类似Fri, 2 Aug 2024 18:02:15 -0000 (UTC)的日期，该格式包含多种变体：

Fri, 2 Aug 2024 18:02:15 -0000 (UTC)
Fri, 2 Aug 2024 18:02:15 +0000 (UTC)
Fri, 2 Aug 2024 18:02:15 0000 (UTC)
Fri, 2 Aug 2024   18:02:15   -0000 (UTC)
Fri, 2 Aug 2024 18:02:15 0000 (UTC)
Fri, 2   Aug   2024 18:02:15 -0000 (UTC)
Fri,                 2 Aug 2024 18:02:15 -0000

该正则在PCRE模式下可匹配所有示例，但使用CTRE编写的代码时，匹配结果仅返回整个字符串；同时在Visual Studio 2022 MSVC 19.40环境下，Debug模式编译需15秒，Release模式需约30分钟。CTRE代码如下：

static constexpr ctll::fixed_string ctll_pattern = { R"((?<weekday>\w{3}),\s+(?<day>\d{1,2})\s+(?<month>\w{3})\s+(?<year>\d{4})\s+(?<hours>\d{2}):(?<minutes>\d{2}):(?<seconds>\d{2})\s+(?<timezone_offset>[+\-]\d{4})(?:\s+\((?<timezone_name>\w+)\))?)" };
static constexpr ctll::fixed_string ctll_weekday = "weekday";
static constexpr ctll::fixed_string ctll_day = "day";
static constexpr ctll::fixed_string ctll_month = "month";
static constexpr ctll::fixed_string ctll_year = "year";
static constexpr ctll::fixed_string ctll_hours = "hours";
static constexpr ctll::fixed_string ctll_minutes = "minutes";
static constexpr ctll::fixed_string ctll_seconds = "seconds";
static constexpr ctll::fixed_string ctll_timezone_offset = "timezone_offset";
static constexpr ctll::fixed_string ctll_timezone_name = "timezone_name";

std::string s_weekday, s_month, s_timezone_name;
int day = 0, year = 0, hours = 0, minutes = 0, seconds = 0, timezone_offset = 0;

const auto all_matches = ctre::multiline_search_all<ctll_pattern>("Fri, 2 Aug 2024 18:02:15 -0000 (UTC)");
for (const auto& match : all_matches)
{
        std::cout << match.to_string() << "\n";
}

一、CTRE导致匹配异常的特性分析 #

1. 正则本身的局限性
   原正则中timezone_offset的匹配模式为[+\-]\d{4}，要求必须带正负号，但示例中存在不带正负号的0000格式，这类内容在CTRE和PCRE中都无法匹配。用户误以为PCRE能匹配所有示例，大概率是测试时使用了修改后的正则（比如添加?改为[+\-]?\d{4}）。

2. API使用与输出逻辑的误解
   match.to_string()的设计就是返回整个匹配的字符串，而非单个捕获组内容。用户的代码仅输出了整个匹配结果，没有通过match.get<ctll_weekday>()这类方式访问捕获组，因此看起来只返回了完整字符串，并非CTRE捕获组功能异常。

3. CTRE的多行模式行为
   使用multiline_search_all会启用多行模式，该模式下^和$会匹配行首/行尾，但用户的正则未使用锚定，因此单行输入下不会影响匹配结果。但如果输入包含多行，可能会匹配多个行内容，若无需多行匹配，改用ctre::search或ctre::match即可。

4. 命名捕获组的细节差异
   虽然CTRE支持(?<name>...)命名捕获组语法，但需确保ctll::fixed_string定义的名称与捕获组名称完全一致（大小写、拼写均需匹配）。若存在拼写错误，会导致无法正确获取捕获组内容。

二、加快CTRE代码编译速度的优化方法 #

CTRE是编译时正则引擎，复杂正则会触发大量模板实例化，尤其是Release模式下编译器的深度优化会进一步拉长编译时间。可通过以下方式优化：

1. 简化正则表达式 #

• 将\s+替换为 +（若仅需匹配空格，而非所有空白字符），减少字符集匹配的复杂度；
• 明确匹配范围，比如将\w{3}改为[A-Za-z]{3}（因为星期、月份均为英文字母），缩小匹配分支，降低编译器分析压力；
• 若部分捕获组非必需，改为非捕获组（(?:...)），减少模板实例化的数量。

2. 调整编译器优化选项 #

• 在Release模式下，将/O2优化级别改为/O1，减少过度优化带来的编译时间开销；
• 禁用/GL（全程序优化），该选项会增加模板密集型代码的编译时间；
• 关闭不必要的诊断选项（如/W4改为/W3），减少编译器的代码检查时间。

3. 优化CTRE API使用 #

• 若仅需匹配单个字符串，改用ctre::match或ctre::search替代multiline_search_all，避免不必要的多行模式处理和全局搜索逻辑；
• 将正则表达式拆分多个小正则，分阶段匹配日期、时间、时区部分，降低单个正则的复杂度。

4. 工程层面优化 #

• 将CTRE头文件包含在预编译头中，避免每次编译都重复处理CTRE的模板代码；
• 升级至最新版本的CTRE，新版本通常会优化编译时模板处理逻辑，减少编译时间；
• 若项目允许，使用/Zc:preprocessor启用C++标准预处理器，提升模板代码的编译效率。

内容的提问来源于stack exchange，提问作者Eshy