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
> 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
>> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk