Rozental, Gennadiy wrote:
Now about config file feature.I have 2 major issues with your design. 1. You again placed 2 eggs into same basket. There are 2 levels of configuration file reading a) level that is responsible for comments lines, empty lines, continued lines, include, ifdef, defines and so on b) level that is responsible for variable definition in configuration file
I disagree. The program options library has one core class for desribing options -- options_description. It's not coupled to any parser. The config_file is a parser for concrete format. It really has the 'add_option'
method, but it's there to make the class complete.
There's real posibility that people would say: I want *only* to parse config file, I don't want any large dependencies. They can you config_file directly.
The parameter validation facilities in config_file are really minimal. While
it would be possible to separate those facilities, I don't know what it will give you. Any nontrivial usage requires options_description already, and that's competely because. The "minimal" usage will be more complicated.
This parses ambiguously for me. To you mean that the configuration of the first level is given in XML? Or that first level parses configuration data in XML? Assuming the latter, I don't see any problem. You'd haveOne may want to use only first level and it's configuration is supplied as XML
options_and_arguments
parse_xml_config_file(std::istream&,
const options_description& desc);
Everything is described in 'desc' and the implementation of the function,
can use it in anyway it likes. For example, by obtaining all options from XML tree and checking if they are allowed.
I'm not able to comment in detail without seeing the code. However,
2. Look closely on config_file interface:
operator++,
operator bool
Does not it look like something familiar? I have a solution based in iterator_adaptor that present iterator interface:
config_file_iterator that manage level a) of configuration reading. It's
very flexible and allows you to configure almost every part of it's logic.
For example comment char, line continuation char and so on.
whether it's iterator or not is not much import, IMO. The basic usage
I'm envisioning does not require to even explicitly create config_file
instance!
And what the flexibility for? Every config files I've see use the same
format. Everybody know that format. If your code allows to treat "\" as comment character and "#" as continuation character, what advantages does it give. In short: do you have a concrete example where this flexibility is used?
I also have a solution that works based on config_file_iterator - parameter_handling. It allows to access multi level (with namespaces and sub namespaces) parameters defined in config file.
And this solution is not compatible with the command line handling, right? - Volodya _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
