From: williamkempf_at_[hidden]
Date: 2001-03-02 09:46:37
--- In boost_at_y..., Aleksey Gurtovoy <alexy_at_m...> wrote:
> William Kempf wrote:
> > Most of us have written code to parse command lines.
>
> Or classes to do it :)
>
> [snip]
>
> > So... I set out and created a reusable parser that is
configurable to
> > accept various "traditional" styles, both Unix and Windows/DOS
with
> > several variants on both, and that allows you to interpret the
> > options/switches in accordance with it's locality on the command
line.
> >
> > This isn't your typical Boost library, but I was wondering if
there
> > would be interest any way?
>
> I am very interested too. IMO a command line parser is a perfectly
> appropriate library for Boost. Also, I believe that there is some
relevant
> prior art on the topic that we might want to study / get ideas
from. For
> what it's worth, here is a link to one of such sources - Brad
Appleton's
> "Options" library -
> 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.
I'd recommend that everyone look at his library, however. My
opinions may not be in a majority on this one. If a library more
along the lines of Options would suit Boost more then we should look
into it instead of mine (or into creating another one along those
lines).
There seems to be enough interest, so I'll polish up the code a bit
and put it into the Files section here later today.
Bill Kempf