boost::spirit alternative解析器解析正则字符类出现结果重复问题排查

问题根因 #

出现[11]重复输出的核心原因是Spirit.Qi 回溯机制的属性状态不同步问题，实际解析流程完全对应测试输入的行为：

1. 解析字符类时，识别到开头的[，把这个字符写到输出字符串里，迭代器移到字符类内部1的位置。
2. 触发tok_set_item规则匹配，先尝试左侧的tok_range分支：
   • 第一步执行tok_char匹配，成功定位到当前位置的1。因为tok_range声明的返回值是std::string，Spirit 会把这个匹配到的1直接追加到tok_set_item的目标输出字符串里。
   • 第二步尝试匹配qi::char_('-')，发现当前位置是]，匹配失败。这时候解析器只会把迭代器退回到tok_range规则的起点，但不会擦掉已经写到目标输出字符串里的那个1。
3. 左侧分支匹配失败，切换到右侧的tok_char分支重试：
   • 又一次成功匹配到当前位置的1，再把这个1追加到同一个输出字符串里。
4. 最后解析完字符类的剩余部分，把末尾的]写到字符串里，最终结果就是[11]。

核心疑问对应解答 #

1. 为什么输入"[1]"会生成"[11]"
   本质是Spirit.Qi 的回溯逻辑只负责恢复迭代器位置，不会回滚容器型属性的写入状态。对于std::string这类可动态增长的属性容器，分支匹配失败时不会自动清空已经追加的内容，导致同一段输入字符被两个分支重复写入到输出里。
2. 无显式动作时的隐式属性传递是否是诱因
   这个问题确实和隐式适配逻辑直接相关：
   • tok_range的原生结构是「单字符-横杠-单字符」的三元素序列，tok_char的原生属性是单个char，二者和tok_set_item声明的std::string返回类型并不匹配。
   • Spirit 在做类型适配时，会把所有子规则的匹配内容直接追加到目标字符串上，没有为每个分支做独立的临时属性隔离，才会出现分支失败后的残留内容污染。
3. 引入qi::as_string[...]能不能解决问题
   这个包装器完全可以解决当前问题。qi::as_string的作用就是给内部的表达式开辟独立的临时字符串存储空间，只有当整个内部表达式完全匹配成功了，才会把临时存储的内容写到外部的目标属性上；如果内部表达式匹配失败，这个临时空间会直接销毁，不会给外部属性留任何残留写入。用这个包装器把tok_range包起来之后，之前的残留问题就会消失，输出就能回到预期的[1]。

长期优化建议 #

如果想从规则设计上彻底避开这类问题，可以把每个子规则的返回类型和表达式的原生属性结构对齐：

• tok_char直接声明为返回char类型，即qi::rule<Iterator, char()>
• tok_range直接声明为匹配三元组的结构体类型
• tok_set_item直接声明为对应变体类型
  这种设计下因为用的都是平凡值类型，回溯时会自动恢复成默认值，不会出现容器属性残留的问题。

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