Re: [boost] Re: Command Line Parser

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-03-02 13:48:01

From: Beman Dawes <bdawes_at_[hidden]>
> At 02:46 PM 3/2/2001 +0000, williamkempf_at_[hidden] wrote:
> 
>  >> http://www.enteract.com/~bradapp/ftp/src/libs/C++/Options.html.
>  >
>  >I've looked at his library as well in the past.  In many ways his
>  >design is very nice and allows for things that mine does not.  For
>  >instance, it automatically generates usage instructions based on the
>  >defined options.  It also lets you create new "option types" that can
>  >parse unusual option syntax.  However, what makes this library nice
>  >is also what I didn't like about it ;).  Since it generates the usage
>  >instructions you're locked into only one way of parsing command line
>  >options (a very flexible way, yes, but I can still see ways in which
>  >it's not flexible enough, mostly when locality matters).  It's also
>  >prone to ambiguous parsing problems if you're not careful with how
>  >you define the options, and while this is true for any parser it's
>  >less obvious when this will occur with his.
> 
> The case comes up over and over where Library Complete is truly wondrous, 
> but Library Simple provides 90% of the same functionality, yet in only 30% 
> of the lines of code.
> 
> Now if Library Complete's added functionality would only rarely be used, 
> and comes at the cost of being harder to learn or use, or more error prone, 
> you might find that users actually preferred Library Simple.
> 
> Without looking at either Command Line Parser, my guess is that simple 
> would win out over complete in this application.  KISS.

I fully agree with KISS, but generating usage instructions is
very important.  I hate utilities that give no usage message,
or just a cryptic list of flags, especially when the man pages
are missing or inscrutable.  See the Unix "find" command for a
particularly egregious example (find: path-list predicate-list).

And also without looking at the code, I'm willing to bet that
by making good use of existing Boost libraries and generic
programming techniques one could get both power and simplicity.
The general problem seems to be to specify the syntax of the
command line, parse a given command line, and then control the
flow of a program given that parse.  The syntax could be given
by a generative specification, with lambda expressions used to
specify program behavior.

And now it's back to the salt mines for me...