From: Jeff Flinn (TriumphSprint2000_at_[hidden])
Date: 2006-04-24 09:41:14
Marcin Kalicinski wrote:
>> The design appears to be appears to be adequate
>> at first, but the more time
>> I spent with working through the examples, the less I liked it.
> Please could you state specific things you didn't like.
>> I think the implementation is pretty good. Overall, the
>> author(s) have utilized
>> modern c++ and established boost's "best-practices",
>> including using boost::spirit for the "xml" parser.
>> I'm not sure why he didn't use boost::spirit or
>> boost::xpressive for the
>> other parsers though.
> Here's the current implementation status of various parsers:
> XML - Spirit
> JSON - Spirit
> INI - not using Spirit
> INFO - not using Spirit
> Registry - irrelevant
> Cmdline - irrelevant
> The reason I didn't use Spirit to parse INI file is its simplicty. If
> you look in ini_parser.hpp, read function fits on one screen. This
> will not be considerably simpler with Spirit, it might even be longer
> if you consider that you'll need to define grammar,
A explicit grammar<> is not necessarily required, you can construct the
rules in place in the call to parse, or use functor parsers. The benefit of
using spirit is that the grammar or rules can be easily compared with the
ebnf for the file format and be determined to account for all valid .ini
files. The comments could also then be preserved as well as PT nodes.
> function objects
> for actions. I agree it would be more maintainable with Spirit.
The function object IMO should be part of the by the PT library 'parser'
interface. This is the back_end interface when one wants to parse their own
format and populate a PT. These would be common to all formats, and lend
credence to the PT library being format agnostic.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk