On 12/01/2010 11:08 AM, Robert Ramey wrote:
The benefit of using spirit to make a parser is that reduces the task to rendering the grammer as BNF or PEG syntax. Subsequent maintainence is reduced to tweaking the grammar.
Firstly, you are preaching to the choir. I am usually the one within the organization to be saying these things, so it feels weird to argue the other side the least little bit. Consider me to be telling you what my coworkers/boss would be expected to say, knowing me as they do.
Writing a "correct" and "robust" parser for some grammer x in C or C++ is much more work than it first appears. It is also extremely tedious and error prone. The worst is that it is very easy to make a "first cut" which works "pretty well" and that decieves one into thinking that he's about done when in fact there is a lot of tweaks in the pipeline end point cases, and lots of unanticipated errors.
Dude, it's something like 17 states: http://www.json.org/ Consider our "risk to schedule" added by a couple of hundred lines of non-abstract C code vs. mastering a new Boost metaprogramming DSEL. There are also several MIT-like licensed implementations available to choose from. And of course there's always the "everybody on the team needs to know it in case that one guy gets hit by a bus" (i.e. fired).
Using spirit mostly eliminates these problems. Spirit does take some time to learn. Using a declarative syntax takes getting used to. And there are hiccups with TMP. But all in all, it is a much better way to get the most of one's brain.
Well said.
It results in a better defined, more complete, more robust, more correct and cheaper to maintain and upgrade final product.
I would like to be able to say that from my own experience.
I personally would be suspicious of a library submission which could use it but declines to do so. Actually, parsing a JSON file would best rendered as an example application for spirit.
Yeah, I think it would make a great example. When I had tried it, I referred to the calculator examples a lot. But they calculate the result and return just that! I wanted to build something very close to the parse tree, but had significant trouble figuring out how to construct the node types and pass them upwards. The features for automatically constructing the return value were the most promoted by the documentation. It seemed to work great for things like ints and doubles, things that have an obvious primitive representation in C++. But the automatic facility seemed to just get in the way as soon as I wanted to return custom structs. There was the XML DOM example, but it was not simple enough for me. Thanks, I'm joining the Spirit list now. - Marsh