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

From: Vincent N. Virgilio (virgilio_at_[hidden])
Date: 2003-02-18 22:16:31

FYI, xParam (sourceforge) seems to fulfill similar requirements.

In article <200302181815.h1IIFbC15551_at_[hidden]>, Rob
Stewart wrote:
> From: Vladimir Prus <ghost_at_[hidden]>
>> Rob Stewart wrote:
>> 
>> > 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.
> 
> I think we're saying the same thing.  My point is that the
> library should abstract the parsing such that the program need
> only describe the supported options and query to learn which have
> been set and with what values.  The format those parameters take
> on the command line or in a configuration file should be hidden.
> 
>> > 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.
> 
> I can't access that page, but I was simply suggesting that the
> library can expose a rather minimal set of types gleaned from the
> command line.  Client code can transform from those types to
> anything else desired.  Boolean and string parameters are
> obvious.  Nothing else is needed as strings can (obviously)
> represent all other arguments.
> 
>> > 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"?
> 
> I see two libraries in what you've proposed: one that manages
> command line parsing and one that manages configuration file
> parsing.  If command line and configuration file parsing are
> completely abstracted from the parameter
> specification/management, then it's a question of what
> configuration formats are provided by default, possibly bloating
> client code unnecessarily.
> 
>> > 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?
> 
> An automatic help message is certainly useful; I simply didn't
> mention it specifically.  Custom value interpretation strikes me
> as overkill.  If your library provides a string corresponding to
> a particular parameter, I can use that string in myriad ways to
> produce information for my program.  Putting that logic into a
> command line parsing library seems over the top.
> 
>> Could you please tell which features in both designs are unnecessary and 
>> should be removed?
> 
> I don't know the full set of features either of you have provided
> at the moment, but I hope the above clarifies my thoughts on the
> scope of such a library.
> 
> I'll second the question raised regarding the more complex
> parsing: isn't that the job of a tool like Spirit?  Be careful to
> avoid doing too much in this library.  You can make it really
> powerful and capable, but that alone may keep too many at bay.
> 
>