Re: [boost] Library for configuration file parsing

Subject: Re: [boost] Library for configuration file parsing
From: Joel de Guzman (joel_at_[hidden])
Date: 2010-12-01 19:04:06

On 12/2/2010 4:59 AM, Marsh Ray wrote:
> 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).

I'd say that anyone parsing text should at least have some knowledge
of formal grammars and BNF. Reading a few lines of lines of declarative
EBNF/PEG vs. hundred lines of non-abstract C code? You know what I'll
prefer. This debate reminds me of the original Mozilla HTML parser written
wayyy back using a hand-crafted state machine and a humongous switch.
Sure it will work, but then you have to add another feature sometime soon
and it gets pretty-exponentially nasty. In fact, I'd argue the other way:
*THAT* should be your concern for potential security holes.

>> 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.
>

Robert has been using Spirit with Boost Serialization's XML parser.
He wrote it once many years ago and had no problem with it at all
(at least none that I am aware of). It's churning along just fine
and he does not have to go back to it, let alone stepping through
the code. It just works!

>> 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.

This is the typical hurdle. We intend to seriously tackle that
very problem. For now, additional information would help a lot.
I'd recommend going through Michael Caisse's splendid BoostCon
slides.

> 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.

See you there.

Regards,
-- 
Joel de Guzman
http://www.boostpro.com
http://spirit.sf.net