原文:http://www.ibm.com/developerworks/cn/aix/library/au-boost_parser/
本文介绍了 Boost 的高扩展性 Spirit 框架。该解析器生成程序遵循 Extended Backus Naur Form (EBNF) 规范并使用 C++ 语言编写,可以显著缩短开发时间。
C++ 程序员需要面对的最复杂的任务之一就是在一段合理的时间期限内编写一个解析器。在为 SQL 或 C++ 这类成熟的语言开发编译器时,使用 GNU Flex/Bison 或 ANTLR 解析器生成程序通常是不错的选择;但是对于使用更简单的 Backus Naur Form(BNF)的语法,这些工具陡峭的学习曲线并不总是物有所值。另一种替代选择是使用标准 Linux® 发行版附带的正则表达式库或 Boost regex
或 tokenizer
库,但是它们不能根据日渐复杂的语法进行良好扩展。
本文介绍了来自 Boost 的高可扩展性 Spirit 解析器框架。该解析器生成程序遵循 Extended Backus Naur Form (EBNF) 规范并使用 C++ 编写,可以显著缩短开发时间。要进一步阅读,请查看详细的 Spirit 文档。
您可以从 Boost 的 Web 站点免费下载 Spirit 框架(参见 参 考资料 小节)。在开始使用 Spirit 进行开发之前,需注意以下事项:
- 必须在源代码中包含
<spirit.hpp>
头文件。该头文件将大量使用元模板编程和仿函数(functor)。本文的所有代码均使用 g++-3.4.4 进行编译。确保使用支持 C++ 特性的编译器。 - 部分 Spirit 框架在内部使用来自 Boost 的正则表达式库,在已安装的代码库中检查
regex.h
头文件。 - 确保 Boost 安装的根目录位于编译器的
include
搜索路径中。 - Spirit 是一个只包括头文件的库,因此在链接时不需要任何额外的库。但是
regex
是一个例外。要将regex
源代码只作为头文件包含,可在代码中使用预处理器指令define BOOST_SPIRIT_NO_REGEX_LIB
。
如果提供一个随机的单词列表,您的第一个 Spirit 项目将使用 C++ 风格列出列表中 Hello World (即 Hello 和 World 两词在输入流中连在一起出现)出现的次数。参见清单 1;清单 2 显示了输出。
清单 1. 列出单词 Hello World 在输入流中出现的次数
#define BOOST_SPIRIT_NO_REGEX_LIB |
Spirit 框架的强大在于它为大量基本类型提供了内置解析器,包括单独的字符、数字和字符串。更复杂的解析器通常都使用这些内置解析器对象创建。在 清 单 1 中,str_p
和 anychar_p
都是 Spirit 中预定义的解析器 —— str_p
匹配它所提供的字符串(在此为 Hello World )并成功调用 increment_a
例程将计数加 1。anychar_p
是另一个预定义解析器,它可以匹配任何字符。
让我们看一看 parse
函数,它实际上是 Spirit 框架中最重要的例程。它接受一个输入流和一个语法,并在内部通过语法运行此输入流。在本例中,输入流来自 input.c_str()
, 而 str_p
和 anychar_p
为语法提供语义。如果熟悉解析的话,将很快就明白 parse
函数的第二个参数相当于提供了一个 BNF。
考虑符合以下模式的解析器:<employee name: string> <employee id: int> <employee rating: float>
。您需要根据从该字符串提取的数据填充 Employee
数据结构。下面是一个典型的字符串:"Alex 8 9.2 Jim 91 5.6"
。
Spirit 为字符串(alpha_p
)、整数(int_p
)、和实数(real_p
) 预定义了解析器。因此,可以认为 parse
例程应该使用以下语法调用:parse(input.c_str(), alpha_p >> int_p >> real_p)
。这里的逻辑是 parse
将在输入流中首先查找一个字符串,然后查找整数,最后查找一个实数。这样可行吗?行不通。清单 2 展示了可以解析数据的可行代码片段。
清单 2. 使用 alpha_p、int_p 和 real_p 预定义解析器
#define BOOST_SPIRIT_NO_REGEX_LIB |
初始调用失败有以下几个原因:
-
alpha_p
解析了单个的字符。要解析字符,必须使用+alpha_p
(这类似于 EBNF+
操作符,表示一个或多个字符,不同的是 Spirit 在前面而不是后面使用它)。 - 使用空格分隔字符串、整数和实数。必须解释这种行为。可以通过两种方式实现:使用
' '
;或者使用blank_p
预定义解析器,这更好,它同时解释了空格和制表符。
下面是修改后的解析调用:
parse(input.c_str(), *((+alpha_p) >> ' ' >> int_p >> ' ' >> real_p) >> !blank_p); |
第二个参数严格匹配一个非字母和数字组成的字符串,该字符串后面依次为空格、整数、另一个空格,最后是一个实数。当解析器达到实数后,它将查找一个 空格/制表符,并重新开始匹配序列或终止。!
操作符表示空格/制表符出现了 0 次或 1 次。*
操作符表示该序列出现了 0 次或 1 次,并因此匹配一个空字符串。
显然,第二个字符串与传统解析器使用的潜在语法规则之间存在直接联系。下面是针对当前需求的典型语法规则:
: |
ALPHA
、INT
和 REAL
通常由 lexer 提供。例如,INT
被定义为 (0-9)+。可以使用 Spirit 合并这些步骤。
如果解析器出现了错误,可以使用几种方法诊断2错误。最简单的检验方法是测试 parse
方法返回的数据结构。返回的数据结构被称为 parse_info
,而 hit
字段表示解析是否成功完成。清单 3 展示了来自 Boost 源代码的 parse_info
结构。
template <typename IteratorT = char const*> |
|
Spirit 附带了一些预定义的操作符。表 1 总结了这些操作符及其语义。后面的示例将使用这些操作符。
操作符 | 语义 |
---|---|
x >> y | 匹配 x 然后匹配 y |
x | y | 匹配 x 或 y |
x & y | 匹配 x 和 y |
x – y | 匹配 x 但不匹配 y |
x ^ y | 匹配 x 或 y,但不同时匹配两者 |
*x | 对 x 匹配 0 次或多次 |
+x | 对 x 匹配 1 次或多次 |
!x | 对 x 匹配 0 次或 1 次 |
( x ) | 匹配 x;用于基于优先权的分组 |
x [ function expression ] | 如果匹配了 x,执行函数/仿函数 |
x % y | 对 x 匹配 1 次或多次,使用 y 分隔 |
了解到目前为止所开发的内容之后,现在可以开始定义 C 风格的浮点数语法。清单 4 展示了 BNF。
Real-Number : |
清单 5 提供了等效的 Spirit 语法。
清单 5. 浮点数的 Spirit 语法,与清单 4 的 BNF 等效
Real-Number = Fractional-Part >> ! Exponent-Part |
可以看到,Spirit 上下文中的 Y = A >> B
与解析器上下文的 Y : A B
相同,其中 A
和 B
可以是末端,也可以是非末端。注意,用户并不需要为此类琐碎的操作定义语法:Spirit 已经提供了预定义的 parser real_p
来解析实数。
Spirit 框架的灵活性源于它为常见处理提供了众多预定义解析器。表 2 提供了包含其中一些解析器的列表。
解析器 | 语义 |
---|---|
ch_p | 匹配一个单个的字符。 |
range_p | 匹配从低/高字符对中创建的一组字符中的单个字符。例如,range_p('a', 'z') 匹配 a 和 z 之间的所有字符。 |
anychar_p | 匹配任何单个的字符,包括 NULL 终端符 /0 。 |
str_p | 匹 配一个字符串:例如 str_p("mystring") 匹配字符串 mystring 。 |
blank_p | 匹配空白和制表符组成的连续序列。 |
space_p | 类似于 blank_p ,但它还 匹配返回字符和换行字符。 |
digit_p | 匹 配一个数字。 |
upper_p | 匹配任何 大写字符。 |
nothing_p | 诊断工 具;从不匹配任何内容并且总是失败。 |
本节讨论 Spirit 的另一个强大特性 —— 指令。Pascal 和 VHDL 等大小写敏感语言中的 lexer 要复杂一些,因为它们必须解析 begin 和 BEGin 等内容并为解析器生成相同的标记。Spirit 使用 parser directives 解决这个问题。例如,预定义指令 as_lower_d
将输入流转换为小写(参见清单 6)。
清单 6. 使用 as_lower_d 指令进行大小写敏感的解析
#define BOOST_SPIRIT_NO_REGEX_LIB |
清 单 6 的输出为 1, THis iS a ranDOm sTRInG
。必须理解解析器与解析器指令之间的差异, 后者仅修改附带的解析器的行为,实际上扩充了该解析器的策略。
Spirit 提供了其他预定义解析器的指令和一些编写解析器的方法。让我们看一下 longest_d
解析器指令。考虑清单 7 并猜猜它的输出是什么。
#define BOOST_SPIRIT_NO_REGEX_LIB |
清 单 7 的输出是 0 20245
。为什么会这样?显然,解析期间整个输入缓冲区都没有被使用,因此 status
为 0
。为了理解这一点,需要注意 Spirit 是如何解析的:为示例规则 S : R1 | R2 | .. | RN
提供多个替代选择,左边的内容获得最大优先权。这类似于 C/C++ 处理条件的方式:在表达式 if (x && y)
中,如果 x
为真,则不计算 y
。这种行为有助于保持工具的处理速度。
在本例中,int_p
匹配 20245 —— 但是在这之后它遇到了一个点字符,并且没有处理它的规则。因此,解析器退出。
解决方法是对语法规则的所有可用的替代内容进行重新分组,但是手动重新分组很容易出错。更好的方法是使用 longest_d
指令,该指令将尝试匹配消耗输入流的最大长度的规则。清单 8 展示了修改后的 parse
例程调用。
int status = parse (input.c_str(), |
通过这一修改,输出现在变为 1 20245.1
。
本节将讨论使用 Spirit 框架设计一组用户定义的语法规则。要设计自己的语法,Spirit 要求执行以下操作:
- 创建一个从预定义
grammar
类继承而来的派生类。grammar
类是一个模板类,被其派生类DerivedT
和上下文类ContextT
参数化。语法类的声明如下所示:template<
typename DerivedT,
typename ContextT = parser_context<> >
struct grammar;
- 您设计的派生类必须有一个名为
definition
(可以不修改此名)的嵌套的模板类/结构。definition
类有以下特性:- 它是类型名为
ScannerT
的模板类。 - 语法规则在其构造函数中定义。构造函数被作为引用传递给实际的语法
self
。 - 必须提供名为
start
的成员函数,它表示 start 规则。
- 它是类型名为
清单 9 展示了用户定义语法的基本框架。
struct my-grammar : public grammar<my-grammar> |
假设您希望支持清单 10 所示的简单语法,该语法部分解析 C/C++ 枚举。
enum_specifier : ENUM '{' enumerator_list '}' |
清单 11 展示了相应的 Spirit 代码。程序的输出为 1
,表示成功完成解析。
#define BOOST_SPIRIT_NO_REGEX_LIB |
本文介绍了 C/C++ 框架的解析功能。要了解更多信息,请查阅 参 考资料 。
学 习
- 您可以参阅本文在 developerWorks 全球站点上的 英文原文 。
- 阅读全面的 Spirit 框架文档 。
- 浏 览 技术 书店 ,阅读有关这些主题和其他技术主题的图书。
- AIX and UNIX 专区 :developerWorks 的“AIX and UNIX 专区”提供了大量与 AIX 系统管理的所有方面相关的信息,您可以利用它们来扩展自己的 UNIX 技能。
- AIX and UNIX 新手入门 : 访问“AIX and UNIX 新手入门”页面可了解更多关于 AIX 和 UNIX 的内容。
- AIX and UNIX 专题汇总 :AIX and UNIX 专区已经为您推出了很多的技术专题,为您总结了很多热门的知识点。我们在后面还会继续推出很多相关的热门专题给您,为了方便您的访问,我们在这里为您把本 专区的所有专题进行汇总,让您更方便的找到您需要的内容。
- 开放源码专区 :访问 developerWorks 开放源码专区,获得大量的 how-to 信息、工具和项目更新,帮助您使用开源技术进行开发,并与 IBM 产品结合使用。
- developerWorks 技术活动和网络广播 :关注 developerWorks 技术活动和网络广播。
- Podcasts :收听 Podcast 并了解 IBM 技术专家的最新想法