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