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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-01-20 10:58:31

Trosset Didier wrote:

>  > > As for configuration files, there are myriad formats available
>  > > and I don't think parsing them has anything to do with command
>  > > lines. 
>  >
>  > Parsing -- no. However, as an application programmer I'm interested
>  > if my code should produce some warnings at runtime or not. Command line
>  > and config file are two places where warnings can be enabled/disabled.
>  > I think this similarity should be exploited.
>  >
> 
> In our case, we created such a system. And for the ease of use, it was 
> very important to define any application parameter in a single step. 
> These application parameters can be set either from command line 
> options, configuration file, or have their default value.
> 
> Having two lines to get the value (as we did initialy), first from 
> config file, and then overloading from cmd line options, proved to be 
> error prone. Adding a new parameter went to copy paste these two lines. 
> And often the changes in one line were not replicated exactly on the 
> second. Thus resulting in a flag meaning true on cmd line and meaning 
> false in config file.

You are right.

> We ended up by using a system where the definition of a parameter were 
> done all at once, as in the following:
> 
> Parameter<bool> verbose(      // use verbose as a bool in code
>    false, "verbose output",   // default value & help string
>    Option("verbose", "v"),    // for cmd line --verbose or -v
>    Config("section", "key")); // config file [section] key =
> 
> Leaving the syntax away from the sample above, the rationale was to keep 
> the Option and Config uses at one single place. We also kept the use for 
> the Parameter<> variable as if it was not one.

The approach I've taken now differs in two points:
1. I don't require to use classes provided by library for value access.
    You can store "bool" value into a regular variable, if you like.
    The need to change type of variable is one aspect in which I
    don't like Brad Appleton's library.

2. There's only one name that should be used both on command line an
    config file. I'm not sure this is a problem in practice. It if is,
    I'll think about a solution. The most obvious one would be to extend
    the library via derivation from some classes, but maybe there's a better
    way.

> Following this, new Config classes can be defined to accomodate every 
> config file format. Of course, Option and Config are not mandatory, as 
> in the example above the verbose config option may not be lots usefull. 
> We also added some Arguments classes, used like Option, to specify 
> mandatory arguments.
> 
> But maybe this is one level above the purpose of this library.

No, that's quite in the scope. Hope you'll be able to comment in more
detail once the library reaches formal review.

Thanks,
Volodya