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

From: Rob Stewart (stewart_at_[hidden])
Date: 2003-01-17 13:28:39

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

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.

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.

As for configuration files, there are myriad formats available
and I don't think parsing them has anything to do with command
lines.  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.

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.

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!

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;