Re: Command Line Parser

From: williamkempf_at_[hidden]
Date: 2001-03-02 13:34:45

--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> At 02:46 PM 3/2/2001 +0000, williamkempf_at_h... 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.

Of the two, I'd classify mine as the "Library Simple", though in many 
ways it's "more complete" than the other.  While mine is simple, it 
allows full flexibility, and could be easily used as the 
parser "behind the scenes" of a library as complex as the Options 
library.

> 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.

This may or may not be the case here... that's why I suggested that 
people also evaluate the Options library before deciding this.  I 
think it would be better to take the simpler approach, obviously, 
since that's what I did when I coded this.  However, this approach 
does mean more work for the programmer than the "complete" approach 
taken by the Options library.  It may be that there's a need for 
both, with the Options style library built on top of the simpler 
library I posted.
 
> Without looking at either Command Line Parser, my guess is that 
simple 
> would win out over complete in this application.  KISS.

I believe in KISS, but in this case there's a conflict between 
implementation and usage.  Mine is simpler in implementation (and so 
in many ways more flexible) while the Options library is simpler in 
usage (and so in many ways less flexible).

Bill Kempf