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
> >defined options. It also lets you create new "option types" that
> >parse unusual option syntax. However, what makes this library
> >is also what I didn't like about it ;). Since it generates the
> >instructions you're locked into only one way of parsing command
> >options (a very flexible way, yes, but I can still see ways in
> >it's not flexible enough, mostly when locality matters). It's
> >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
> but Library Simple provides 90% of the same functionality, yet in
> 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
> Now if Library Complete's added functionality would only rarely be
> and comes at the cost of being harder to learn or use, or more
> 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
> 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).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk