Boost logo

Boost :

From: Trosset Didier (didier.trosset_at_[hidden])
Date: 2003-01-20 05:57:57


-----Original Message-----
From: Vladimir Prus [mailto:ghost_at_[hidden]]
>
> > 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.

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.

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.

Regards,
Didier



Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk