2
0
mirror of https://github.com/boostorg/spirit.git synced 2026-01-19 04:42:11 +00:00

X3.Docs: Remove parse_rule implementation details

It is hard to not forget to keep in sync these while anyone interested could simply go to the macro definition, moreover users should not rely on the implementation details and telling this info may make it seem like `parse_rule` is a public API.
This commit is contained in:
Nikita Kniazev
2021-03-06 22:13:03 +03:00
parent 17cbb60c6f
commit 841eeb2d96
2 changed files with 2 additions and 23 deletions

View File

@@ -87,14 +87,7 @@ understanding of what's happening.
Here in the header file, instead of `BOOST_SPIRIT_DEFINE`, we use
`BOOST_SPIRIT_DECLARE` for the *top* rule. Behind the scenes, what's actually
happening is that we are declaring a `parse_rule` function in the client
namespace. For example, given a rule named `my_rule`,
`BOOST_SPIRIT_DECLARE(my_rule)` expands to this code:
template <typename Iterator, typename Context>
bool parse_rule(
decltype(my_rule)
, Iterator& first, Iterator const& last
, Context const& context, decltype(my_rule)::attribute_type& attr);
namespace.
If you went back and reviewed [link __tutorial_spirit_define__
BOOST_SPIRIT_DEFINE], you'll see why it is exactly what we need to use for

View File

@@ -168,21 +168,7 @@ definition using the `BOOST_SPIRIT_DEFINE` macro:
BOOST_SPIRIT_DEFINE(r);
Behind the scenes, what's actually happening is that we are defining a `parse_rule`
function in the client namespace that tells X3 how to invoke the rule. For example,
given a rule named `my_rule` and a corresponding definition named `my_rule_def`,
`BOOST_SPIRIT_DEFINE(my_rule)` expands to this code:
template <typename Iterator, typename Context>
inline bool parse_rule(
decltype(my_rule)
, Iterator& first, Iterator const& last
, Context const& context, decltype(my_rule)::attribute_type& attr)
{
using boost::spirit::x3::unused;
static auto const def_ = my_rule_def;
return def_.parse(first, last, context, unused, attr);
}
function in the client namespace that tells X3 how to invoke the rule.
And so for each rule defined using `BOOST_SPIRIT_DEFINE`, there is an
overloaded `parse_rule` function. At parse time, Spirit X3 recursively calls
the appropriate `parse_rule` function.