To be explicit: one of the "features" this advertises is equivalent to saying "if you stop compiling your code with `-Wall`, you don't have to deal with all those pesky warnings!"

Pressing rules are written in c++ directly, with templates.

Although if you have no experience in parsing, the learning curve could be a bit steep.

Here's the use case:

expr := ...

rule1 := expr foo expr

rule2 := expr bar

When trying to match rule1 and failing, it is great to have the expr part of it already parsed and ready for trying out rule2.

This doesn't have to be done extremely well (see PEG/Packrat parsing for that) but even a little bit, maybe one term or something like that helps a lot.

In my opinion, parser libraries/frameworks indeed are all mired by the usual suspects which make adoption painful:

* Must learn another grammar language which for some strange reason I suspect has to do with "tradition", must reside in _a file_ -- as opposed to just be expressed with code (i.e. `bin_expr = Concatenation(Ref('expr'), bin_op, Ref('expr'))`); if a BNF language _is_ used for grammar, it almost always is used with some non-standard syntax for helping resolve shift/reduce errors, etc -- which for me puts it into the same "this is not needed" category

* Defined by the kind of parser that is generated, so implying you have to know parser theory in order to know what languages you will never be able to parse with said library/framework; made even worse when some kludge is added with extensive documentation on how to get out of the predicament because "the parser cannot theoretically handle the grammar/language but it otherwise is really great because it uses ABC kind of parsing which is why we chose it" -- the impression it gives a person who knows parsing enough to know they need to construct a grammar and that the grammar may feature ambiguities, is that they have to learn more parser theory; when you learn more parser theory, you usually just implement your own parser unless you need to parse e.g. C++, admittedly; for case in point, see my remark on the "recursive descent parser" being used with Lexy

To be frank, I like the addition of yet another parser generator -- the more the merrier, because contrary to that one earlier statement, that "parsing is a solved problem", I think it is not -- the theory has substantial headway on the practice, meaning that in theory it is [a solved problem], but in practice it is not, in my experience.