在过去的几周里，我一直在阅读和玩flex / bison，主要目标是使用嵌套的组和列表来解析结构化配置文件。
flex / bison似乎非常强大但太复杂了。
我调查了一些开源项目，我发现使用Bison进行配置解析的唯一例子是ntpd，其他项目构建了自己的解析器和词法分析器。
这真的是适合这份工作的工具吗？或者手动构建递归下降解析器更好（可以使用flex作为词法分析器）？！
答案 0 :(得分：2)
这完全合适。如果你精通野牛，你可以比编写RDP或某种特殊解析器更快地将它放在一起。如果你是第一次接受它可能需要更长的时间 - 但它也可能是一种很好的学习方式。
它还可以帮助你设计你的语法 - 如果你不小心使它变得模棱两可，你马上会得到一个R / R冲突，而不是在你的RDP中找到一个depp黑暗的地方，并发现你有没办法......
答案 1 :(得分：2)
我不相信它太复杂了。此外，与自动生成的解析器相比，手写解析器的可维护性很差。
GNU Bison和Flex的最大问题是没有很好的C ++教程。有很多写得很糟糕的C示例带有全局变量，它们不会帮助 Bison / Flex 声誉。当你有一个有效的例子时，你的感知可能会改变。
这是一个使用 Bison 3 和 Flex 的 C ++ 解决方案。将它封装在你自己的命名空间中瞧 - 你可以用gazilion解析器填充你的项目。
答案 2 :(得分：1)
有很多家庭酿造配置文件语法是使用原始ad-hoc方法开发的，例如基于简单的标记化将行拆分为名称和值。这些方法tend to have limitations和Java属性文件以a particularly bad configuration format的形式出现在我们的脑海中。
当您决定为配置语法定义词法和BNF规范时，您已经领先于游戏。然后，您是选择通过手写代码还是通过flex＆amp; amp;等工具来实现该规范。野牛只是一个相对不重要的实施细节。
当我设计并实施Config4*时，我为reasons I discuss in one of the Config4* manuals选择了手写代码方法。但是，我同意BadZen的建议：如果你已经习惯使用flex和bison，那么与使用手写lexer和递归下降解析器相比，使用它们可能会节省时间。