Re: [boost] Re: arguments parsing, wildcard matcher

From: Vladimir Prus (ghost_at_[hidden])
Date: 2001-11-19 04:48:30

> I U/L a command line parsing concept to the Files section some time
> ago.  It's a raw parser with few bells and whistles, which seems to
> not be what people want.  However, theres a few things I'd like to
> say about it and would suggest anyone working on a library to do this
> should look at the code.

Yep, absense of bells and whistles is what made me attempt writing my library.

> 1) A command line parser needs to be *extremely* flexible.  Most
> libraries I've seen with easier and more OO APIs restrict you to the
> simple format of:
>
> prog [options] [free arguments]
>
> Where typically the options can take a single argument or have some
> issues with when/how multiple arguments for an option can be
> specified.  A good parser should allow multiple arguments per option
> as well as allowing free arguments to be interspersed within the
> options.  This isn't an easy thing to do and is nearly impossible
> with the simpler APIs.

AFAICT, the interface that I use for describing options syntax does not 
preclude mutliple options at all. The only problem with interspersing options 
and arguments is ambiguity arising with optional parameters.
"--foo bar" can mean two different things if "foo" takes optional parameter. 
Should we be greedy in this case?

> 2) The "style" of the platform should be adhered to, unless
> specifically specified to be different.  In other words, Unix folks
> are used to -x and --xxxxx for short and long options, while Windows
> folks are used to /x with various methods of handling long options
> (/xxx with exact match or /xxx where as long as the subset of the
> full long option character set is unique it's accepted, etc.).  Also
> Unix folks are used to case sensitive options, while Windows folks
> frequently see both case sensitive and case insensitive options.
> Unix folks expect --help while Windows folks expect /?.  Etc.

I have slightly different position. IMO, there should be one default style. 
If developers want different style of different OSes, they pass some flags 
explicitly. 

> The library I uploaded tried to comply with these two points.  I
> still think that such a design would be a good low level API allowing
> the most flexibility.  A higher level API can then be built on top
> allowing for easier use for typical cases.

I'll have a closer look at your work.

- Volodya