我想在 C++ 中做一些正则表达式，所以我查看了 interwebz（是的，我是 C++ 的初学者/中级）并找到了这个 SO 答案。
我真的不知道在 boost::regex 和 boost::xpressive 之间选择什么。有什么优点/缺点？
我还读到与 boost::regex 相对的 boost::xpressive 是一个仅限标头的库。在 Linux 和 Windows 上静态编译 boost::regex 很难（我几乎总是编写跨平台应用程序）？
我也对编译时间的比较感兴趣。我有一个使用 boost::xpressive 的当前实现，我对编译时间不太满意（但我没有与 boost::regex 的比较）。
当然，我也对正则表达式实现的其他建议持开放态度。这些要求是免费的（就像啤酒一样）并且与http://nclabs.org/license.php兼容。
一个相当重要的区别是 Boost Regex 可以支持链接到 ICU 以获得 Unicode 支持（字符类等）Boost Regex ICU Support。
据我所知，Boost Xpressive 没有内置这种支持。
在使用 Boost 库时，由于跨平台兼容性问题，我倾向于使用仅标头库。不利的一面是，当您的编译器报告与您使用该库有关的错误时，仅标头输出倾向于神秘。
假设您使用的是相当新的编译器，那么它很有可能已经包含了一个正则表达式包。试着做#include <regex>，看看编译器是否找到它。
唯一的窍门是它可以在两个不同的命名空间中的一个（或两个）中。正则表达式包含在 C++ 标准的 TR1 中，并且也在 C++11（的最终草案）中。TR1 版本位于名为 的命名空间tr1中，标准版本位于 中std，就像库的其余部分一样。
FWIW，这本质上与 Boost 正则表达式相同，而不是 Boost Xpressive。
好吧，如果您需要在运行时创建正则表达式（即让用户输入正则表达式进行搜索），您不能使用xpressive它，因为它只是编译时。
另一方面，由于它是一个编译时构造，它应该比优化器受益更多regex。
我用 Boost.MPL、StateChart 和 Spirit 做了足够多的事情，以至于 220KB 的编译器警告和错误并没有真正困扰我。如果这对您来说听起来很糟糕，请坚持使用 Boost.Regex。
如果您确实使用 xpressive，我强烈建议您打开，-Wfatal-errors因为这将在第一个 'error:' 行之后停止编译（以及更多错误）。
对于编译时间，这不是竞争。Boost.Regex 会更快*。xpressive 使用 MPL 的事实将导致编译时间显着增加。
*这假设您只构建 dll/so 一次
我会尝试通过以更理论的方式更深入地研究编译时正则表达式（CTR）与运行时（动态）正则表达式（RTR）的主题来补充其他人的答案（这个主题是由OP问题间接暗示的恕我直言） . 运行时正则表达式更广为人知和流行（大多数语言核心库实现），我想是由于历史原因。与 CTR 不同，当在运行时确定正则表达式时，它们是可以的。两者都在有限状态机的基础上工作。
RTR由某种通用有限状态机“编译”和解释（通用意味着它的解释器类型，该方案在运行时给出，在某些内部数据结构中“编译” - 当您传递正则表达式字符串时，然后在运行时解释-时间）。
但是 CTR 是在编译时“编译”的，并且特定于特定的正则表达式，因此当在运行时给出正则表达式时（文本编辑器、文件/互联网搜索引擎等应用程序），您不能使用它们。
但是它们比具有该机器的表预设方案的解释器（一些类似的情况是反射字段访问与编译时访问，或专门如那里指出的，针对某些固定参数优化的函数）。另一个优点是编译时语法检查。CTR 可以通过元编程和/或代码生成来实现。
至于具体的实现——RTR 有很多，但 CTR 没有那么多。对于 C++，它们是上面提到的 Boost 和 STL C++0x11 实现。您可能需要它们来优化生成代码/内存使用的正则表达式性能/大小，主要与嵌入式系统或高性能特定应用程序相关。 关于 CTR 的 SO 问题 寻找 CTR 实现更难，如果找到一个例子是 Re2C 代码生成器项目、Java CTR 实现和 C# 实现，具有 Regex 的运行时编译（到 IL 代码，而不是内部数据结构）[有关于它]
PS对不起，由于声誉问题，无法发布一些相关链接