I have a symbol table (essentially mapping different types to a enum class of the types I am supporting), which I would like to reuse in several parsers. The only example of symbol tables I could find is the roman numerals example, which is in a single source file.
When I try to move the symbol table into its own cpp/h file in the style of the more structured examples my parser will segfault if I try to parse any string which is not in the symbol table. If the symbol table is defined in the same compilation unit as the parsers that use it throws an expectation exception instead (which is what I would expect it to do).
My questions: - Why does moving the symbol parser to a separate compilation unit cause a segmentation fault in this case? - What is the "correct" way of making a symbol table reusable in multiple parsers? (In the MCVE I obviously only use the fruit parser in one other parser, but in my full project I want to use it in several other parsers.
Re: Boost Spirit X3 Symbol table parser segfaults when in a separate compilation unit
On 28-04-17 13:36, Sigbjørn Lund Olsen wrote:
> I have made a small project which shows what I am trying to achieve and is
> available here: https://github.com/sigbjornlo/spirit_fruit_mcve I think the problem has been resolved in the X3 develop branch
> My questions:
> - Why does moving the symbol parser to a separate compilation unit cause a
> segmentation fault in this case?
As the analysis confirmed, the symbol table has nothing to do with it.
The expectation point is triggering the use of a `nullptr` rule-name.
That's fixed in https://github.com/boostorg/spirit/pull/229
You should be able to verify this by e.g. replacing the fruit rule with
something like `lexeme["Apples"] >> attr(FRUIT::APPLES) |
lexeme["Oranges"] >> attr(FRUIT::ORANGES)`.
> - What is the "correct" way of making a symbol table reusable in multiple
> parsers? (In the MCVE I obviously only use the fruit parser in one other
> parser, but in my full project I want to use it in several other parsers.