[WIP] experimental Spirit X3 hacks #3976
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is an experiment I started because I hate how Spirit X3 separates rules from parsing expressions with the
_def
suffix. Jumping between where a rule is used in the grammar and where it's defined is awkward because they're different identifiers. Well, I could make vim do that with a keystroke, but I chose not to write vimscript for this.C++ allows a name to refer to a type and a variable (or function) at the same time. They don't shadow each other. Although the variable/function takes precedence where it's syntactically allowed, you can always get to the type with an explicit class-key (
struct
,enum
, ...). So I use the same name for theTag
type used to differentiatex3::rule
specializations, and for the variable used in parsing expressions.Rule parsing expressions are stored in a variable template specialized on the
Tag
type. After testing a few variations of this approach, I found it's already been explored (djowel/spirit_x3#17).So there are no suffixes, everything related to a rule is designated by a single name.
The
MyRule
variable could've been simply anx3::rule
instance, but that would suffer from initialization order issues becausex3::rule
constructor is notconstexpr
. So I instead made thestruct MyRule
type usable in parsing expressions (it converts to anx3::rule
).So far I've only converted TopoJSON grammar to this style (despite my opinion that Spirit is not the right tool to parse JSON-based protocols and that this grammar is flawed, I had my hands on it when I got the idea :)). With gcc-6,
topojson_grammar_x3.o
size dropped by ~30k (~10%), that accounts for ~1% oflibmapnik-json.a
. I'm curious whether other grammars will also shrink. I kinda expected the opposite, as I madex3::rule
type signatures longer. Perhaps the reduction is due toBOOST_SPIRIT_DEFINE
putting parsing expressions in function-local static variables, whose names are really long, because they include both the function type and the variable type.