Boost logo

Boost :

From: williamkempf_at_[hidden]
Date: 2001-11-28 12:08:27

--- In boost_at_y..., Vladimir Prus <ghost_at_c...> wrote:
> > I U/L a command line parsing concept to the Files section some
> > ago. It's a raw parser with few bells and whistles, which seems
> > 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
> > should look at the code.
> Yep, absense of bells and whistles is what made me attempt writing
my library.
> > 1) A command line parser needs to be *extremely* flexible. Most
> > libraries I've seen with easier and more OO APIs restrict you to
> > simple format of:
> >
> > prog [options] [free arguments]
> >
> > Where typically the options can take a single argument or have
> > issues with when/how multiple arguments for an option can be
> > specified. A good parser should allow multiple arguments per
> > 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.
> AFAICT, the interface that I use for describing options syntax does
> preclude mutliple options at all. The only problem with
interspersing options
> and arguments is ambiguity arising with optional parameters.
> "--foo bar" can mean two different things if "foo" takes optional
> Should we be greedy in this case?

I never looked at your implementation so I wasn't commenting directly
on what you support or don't. However, the ambiguity you point out
above is precisely why I think we need the lower level interface as
well. In general interspersing options with arguments can't be done
because of these ambiguities, and so higher level interfaces can't
support this. However, it's often possible to handle the ambiguities
directly which is easily done using the interface in the code I

> > 2) The "style" of the platform should be adhered to, unless
> > specifically specified to be different. In other words, Unix
> > are used to -x and --xxxxx for short and long options, while
> > 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.).
> > 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.
> I have slightly different position. IMO, there should be one
default style.
> If developers want different style of different OSes, they pass
some flags
> explicitly.

That's only slightly different then my position. My position is that
when I'm writing a program for platform X it should be EXTREMELY
trivial to have the parser behave as if coded for that platform. If
I have to pass 3 or more options to make it behave this way then the
library is getting in my way. That doesn't mean that I expect the
program to take / as the argument on Windows but - and -- on Unix.
Portable programs should pick a style and use it consistently on all
Bill Kempf

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