From: Rozental, Gennadiy (gennadiy.rozental_at_[hidden])
Date: 2003-01-17 13:57:03
> Since this discussion has been mostly between two folks, I
> thought I'd add my take on command line and configuration file
> handling.
Finnaly. I started to think that it's only me and Volodya who have an
interest in a subject.
> The purpose of command line parsing is to decode the arguments
> list into pieces of information, abstracting the syntax of the
> command line away from the program. Thus, the library should be
> able to understand any of various encoding schemes.
Agree here. That's why lookup_policy is introduced - to support different
logic in parameter identification.
> The question then becomes how the library should provide the
> values from the command line. There are a number of fundamental
> types that could be exposed by the library: bool, long, double,
> and string. The question is whether the library should support
> any others. I selected those types because Boolean and string
> parameters are obviously important, and long and double would
> handle pretty much all numeric arguments one would put in a
> command line.
>
> You could use std::istream-based input mechanisms to allow types
> to parse an input string, thus making the argument to variable
> conversion extensible. Beyond that, I don't think anything is
> needed.
Yes. Once parameter is identified the second task is to parse out value from
input. I separated this logic into interpreter class. Default one use
lexical_cast(istream) based solution. But if for whatever reason you prefer
scanf you will be able to use one.
> As for configuration files, there are myriad formats available
> and I don't think parsing them has anything to do with command
> lines.
Agree here.
> I can see a special redirection mechanism in which you
> tell the command line library that all or some of the arguments
> that would otherwise be on the command line will appear in a
> file, but the format of such a file should be confined to a
> series of lines that conform to what could otherwise have been on
> the command line.
This is only one of the possible solutions to the task of providing unified
program parameters interface.
> Some configuration files include CPP-like preprocessing symbols
> and directives. Some are section based (like Windows INI files).
> Some are just free form lines of text. Some use special symbols
> to delimit required columns of data. I don't think there's a
> good way to standardize this.
>
> Sure, you could provide a means to read a file line by line and
> pass each line to a parser of some sort. However, given all of
> the ways to parse the text one might find in such a file, I don't
> see how that could be done so it is sufficiently flexible and yet
> actually provides value. IOW, the parsing would be little more
> than read a line, give it to the parser, read another line, give
> it to the parser, etc. That certainly doesn't justify a special
> library.
Look on what my config_file iterator is doing. Don't you think it's reusable
and worth separating into library?
Gennadiy.