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

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.