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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-01-20 04:22:32

Rob Stewart wrote:
> Since this discussion has been mostly between two folks, I
> thought I'd add my take on command line and configuration file
> handling.

It's good!

> 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.

That's syntantic level. I believe it should be as independent from
meaning of options as possible: command line, preferrable, should
be immediately parsable by humans.

> 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.

The level 2 of my library provides only syntantic representation
of the read options. See

     http://zigzag.cs.msu.su:7813/program_options/html/

for the list of layers.

> 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.

That's layer 4. You can specify how to interpret values, and by
default stream operations are used. You can easily add something
smarter.

> 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.

> 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.
> 
> 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.

And there's no need. You're welcome to write your own parser and hook
it to the rest of library.

> 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.

What "special library"?

> Perhaps I've missed some valuable service that should be included
> in the proposed library, but I can't see that it should do more
> than what I've outlined herein.  If you do, please enlighten me!

It looks like you don't need some of the extra features that both Gennadiy
and myself are after. For example, custom value interpreration or automatic
help message?

Could you please tell which features in both designs are unnecessary and 
should be removed?

- Volodya