单遍解析器多匹配实现？Spirit调试及Phoenix构造合法性问询

Hey there! Let's tackle your Boost Spirit and Phoenix questions one by one—these are super common pain points when working with Spirit, so you're not alone.

Boost Spirit's lack of obvious error feedback can be frustrating, but there are concrete tools to cut down on trial-and-error time:

• Enable Boost Spirit Debug Macros
  This is the most powerful quick win. Define BOOST_SPIRIT_DEBUG before including any Spirit headers, and it will generate detailed trace logs for all your rules—showing exactly where matching succeeded, failed, or backtracked. If you don't want global debug output, target specific rules with BOOST_SPIRIT_DEBUG_NODE(your_rule_name) instead.
  Example:

  #define BOOST_SPIRIT_DEBUG
  #include <boost/spirit/include/qi.hpp>
  
  // ... your parser rule definitions ...
  BOOST_SPIRIT_DEBUG_NODE(my_log_parser_rule);
  

• Catch Expectation Failures
  When using explicit or implicit expectations (like >> to chain rules), Spirit throws a qi::expectation_failure exception on mismatch. Catch this to print the exact position of failure, the expected rule, and remaining input.
  Example:

  try {
      bool parse_success = qi::parse(input_begin, input_end, your_parser);
      if (!parse_success) std::cerr << "Parse failed without explicit expectation error\n";
  } catch (const qi::expectation_failure<InputIterator>& e) {
      std::cerr << "Failed at position " << std::distance(input_begin, e.first) 
                << ": Expected '" << e.what() << "' but got '" 
                << std::string(e.first, e.last).substr(0, 20) << "...'\n";
  }
  

• Inline Debug Actions
  Insert quick Phoenix-based print actions to track intermediate matches. This helps verify if parts of your rule are working as expected before a full failure.
  Example:

  using namespace boost::phoenix;
  auto debug_match = [](auto& ctx) {
      std::cout << "Matched value: " << _attr(ctx) << "\n";
  };
  auto number_rule = qi::int_[debug_match];
  

Since you didn't finish sharing your specific Phoenix code, I'll cover the most common valid patterns and red flags to check:

• Valid Vector Population with Phoenix
  Using Phoenix to populate vectors in a single parse pass is totally legitimate—this is exactly what Phoenix was designed for! The standard pattern uses phoenix::push_back with a reference to your vector (wrapped in phoenix::ref to enable lazy evaluation) and the parsed attribute (qi::_1).
  Example:

  std::vector<std::string> log_messages;
  using namespace boost::spirit::qi;
  using namespace boost::phoenix;
  
  auto log_rule = *(qi::lexeme[+(qi::char_ - '\n')][push_back(ref(log_messages), _1)] >> '\n');
  

• Key Legitimacy Checks

  • Always use phoenix::ref/phoenix::cref for external variables in Phoenix actions—plain C++ references won't work with Spirit's lazy evaluation model.
  • Ensure your target vectors (or any variables modified by Phoenix) exist for the entire duration of the parse—don't let them go out of scope mid-parsing.
  • Match action argument types to your rule's attribute: if your rule parses a double, your Phoenix action should accept a double (via _1 or _attr(ctx)).
  • Avoid non-lazy constructs (like raw C++ function calls) directly in rules—wrap them with phoenix::bind to keep evaluation lazy.

If you can share a snippet of your Phoenix code, I can give you a more precise verdict on its validity!

内容的提问来源于stack exchange，提问作者Pablo