Boost logo

Boost :

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
> > needs to write the "usage" output which responds to --help or
> > 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
> 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
> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at