RE: [boost] Preliminary submission: command line & config file li brary

From: Rozental, Gennadiy (gennadiy.rozental_at_[hidden])
Date: 2003-01-16 12:39:17

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

You did not get me. I did not talk about options description at all. As I
keep repeating it another level of abstraction on top of config file, cla,
registry, db whatever. The only purpose of option description is to store
unified description of all named options for the program. it does not have
any parsing functionality inside. Instead when you need to get named program
parameters from some source you feed it with option_descriptions and get the
results from it (option_description may also provide unified way to access
named parameter, that in fact will be a forward to component-specific access
method). option_description design IMO is separate issue and should be
discussed separately. Here we talking about config_file component design. So
to clarify my point let me present an example of my configuration file

----------------------------------------------------------------------------
--------------------------
my_tester.def:

# default value; could be reset in environment
$ifndef tester_home
$define tester_home ..
$endif

my_application::ids                "some file name"
my_application::compression  "compression definition file name"

tester::debug            true
tester::trace_config   "trace configuration here"

$include $tester_home/tests_lists

----------------------------------------------------------------------------
--------------------------
tests_list:

test_list::uncompressed::single-message::basic \
          test1 \
          test2 \
          test3

----------------------------------------------------------------------------
--------------------------

My config_file iterator is responsible for 
1. comments lines
2. continuation lines
3. ifdef, define, undef, endif ...
4. include 
5. skipping empty lines

My parameters handling facility is responsible for parsing, storing and
accessing parameters defined in format (configurable) above. It does not
know anything about supported parameter by the program it just read what is
in config file. Later you could access parameters by name and get the value
if parameter with the supplied name exists.

These are 2 layers I was talking about. Note that if my configuration was
not defined in a form <name> <value>, but instead in some other legacy or
XML format, I still could be able to use layer 1. If I need any king of
validation facility (required/optional parameters for example) I could build
it on top of these.
 

> I'm not able to comment in detail without seeing the code. However,
> 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!

My point is that design should be iterator based. For example, I am actively
using STL algorithms with my config_file_iterator.
Whatever helper wrappers you provide doesn't matter.
 
> 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 do. My format is different from yours. But it's not the point. I am sure
that there a lot of legacy formats out there. And if somebody could not use
config_file facility only becouse comment char is $ instead of #, it would
be pity. So again I don't believe such basic facility could afford to be so
restrictive.

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

I did not have a need for that by the time. Once I need it I would introduce
something like option_descriptions on top of both facilities I have.
 
> - Volodya

Gennadiy.