Re: arguments parsing, wildcard matcher

From: williamkempf_at_[hidden]
Date: 2001-11-16 09:02:50

--- In boost_at_y..., Vladimir Prus <ghost_at_c...> wrote:
> 
> David Abrahams wrote:
> 
> > It occurs to me that even in the simplest cases, the programmer 
probably
> > needs to write the "usage" output which responds to --help or 
incorrect
> > options. A truly easy-to-use interface would read and interpret 
the "usage"
> > text, so that the programmer hardly needs to do anything else. I 
have no
> > idea how feasible that is...
> 
> Very interesting idea! Some libraries try to generate usage 
instructions 
> themself, and, IMO, it's simply impossible to generate a decent 
usage message 
> this way. You propose to do quite the reverse! If exact format of 
usage 
> string is defined, it would be very simple to add such a 
functionality to my 
> library. I'll have to think about it....

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.

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.

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.

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.

Bill Kempf