Boost.Spirit、Nabialek 技巧和错误处理

发布于 2024-12-29 10:42:10 字数 689 浏览 1 评论 0原文

是否有可能以某种方式将“通用”错误处理(就像教程中给出的那样)与 Nabialek 技巧结合起来?像这样:

...
on_error<fail>
(
    start
  , std::cout
        << val("Error! Expecting ")
        << _4                               // what failed?
        << val(" here: \"")
        << construct<std::string>(_3, _2)   // iterators to error-pos, end
        << val("\"")
        << std::endl
);

start = *(keyword[_a = _1] > lazy(*_a));

some_other_rule.name("other rule's name");
...

现在,当 some_other_rule 被延迟调用并失败时,错误消息会逐字显示 "lazy" 是预期的,而不是 "other Rule's name" (我需要)。它是否应该以这种方式工作,而我只是在其他地方弄错了,或者还涉及其他一些特定的技巧?

Is it possible to combine "generic" error handling (like it's given in the tutorial) with Nabialek trick somehow? Like this:

...
on_error<fail>
(
    start
  , std::cout
        << val("Error! Expecting ")
        << _4                               // what failed?
        << val(" here: \"")
        << construct<std::string>(_3, _2)   // iterators to error-pos, end
        << val("\"")
        << std::endl
);

start = *(keyword[_a = _1] > lazy(*_a));

some_other_rule.name("other rule's name");
...

Now, when some_other_rule is lazy-called and fails, the error message says that "lazy" was expected verbatim, and not "other rule's name" (which I need). Is it supposed to work that way and I'm simply mistaken somewhere else, or there are some other specific tricks involved?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

夏天碎花小短裙 2025-01-05 10:42:10

好的,我已经解决了(将其发布在这里供遇到问题的人使用):

some_other_rule 以及通过 keyword 解析器选择指针的其他规则应以 <代码>qi::eps> ...。

这是因为lazy本身就是一个解析器,当调用的解析器失败时,lazy会回滚以尝试其他可能的分支。并且由于唯一的期望是它之前的期望 (...>lazy()),因此针对 lazy 引发期望失败。因此,我们所做的就是添加另一个更接近实际误差的期望。

Okay, I've worked it out (post it here for someone who hits the issue):

some_other_rule and other rules whose pointers are selected via the keyword parser should start with qi::eps > ....

That is because lazy is a parser itself, and when the invoked parser fails, lazy gets rolled back to try other possible branches. And since the only expectation is the one preceeding it (... > lazy()), expectation failure is raised against lazy. So, what we do is add another expectation closer to the actual error.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文