何处理浮点数解析 - 扫描仪还是解析器？

我正在设计一个小的领域特定语言的过程。作为扫描仪/解析器生成器，我使用Flex/BisonC++。现在，生成的DSL编译器前端能够解析八进制，十进制和十六进制数字。剩下的唯一剩下的就是在C/C++中对浮点数（FPN）的支持。何处理浮点数解析 - 扫描仪还是解析器？

有在 http://rosettacode.org/wiki/Literals/Floating_point#C

的浮点数语法一个RegExp一）我知道，解析，可以在扫描完成或/和分析器，但我不知道什么是最好的 - 在性能和效率方面。

b）另外一个限制是，我想避免触碰输入的每个字符不止一次，即我想避免使用STL或其他字符串到浮点数转换函数，在解析过程中进行飞行转换。这可能吗？

来源

2012-01-11 user1142580

让扫描器（flex代码）识别并转换浮点数，就像它应该识别和转换整数一样，这是完全可行的，而且通常是合理的。如果您已经在文法（bison代码）中编写了整数识别代码而不是扫描器，那么您可能也会在其中写入浮点识别代码，但这不是它通常的做法。您可能需要为令牌类型使用更复杂的（读取“复杂”）数据类型;请阅读%union。

来源

2012-01-11 07:59:38

整数识别存在于扫描仪中，因此FPN识别应根据干净设计进行。 – user1142580 2012-01-11 10:28:14

对不起，我不清楚以下内容：虽然我可以在扫描程序中实现它，但它会给扫描程序规范带来很多复杂性（涉及大量状态处理），而解析程序中的实现可能更加容易。但是，由于整数识别存在于扫描仪中，因此FPN识别应具有干净的设计。我必须做出的决定是：执行表现如何？是基于扫描仪还是基于解析器的FPN识别更快？ – user1142580 2012-01-11 10:36:12

忽略性能;你可能无法衡量差异。如果可以的话，这将是因为当扫描仪处理FPN识别时语法代码更小（语法不必处理混乱）。如果您将FPN识别功能踢到语法上，您的扫描仪必须将'-23.00456E + 34'作为5个单独的标记（'-23'，'''，'00456'，'E'和'+ 34'，保留前导零，有时你必须处理一个字符两次，后退是不可避免的（例如，你需要在数字的末尾读取一个字符，以知道你已经达到了最后的结果，例如） – 2012-01-11 13:48:29

何处理浮点数解析 - 扫描仪还是解析器？

回答

相关问题