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