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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost