Re: [boost] Re: Using program_options with other options methods

From: Jody Hagins (jody-boost-011304_at_[hidden])
Date: 2004-11-24 07:25:57

On Wed, 24 Nov 2004 10:27:59 +0300
Vladimir Prus <ghost_at_[hidden]> wrote:

> Hi Jody, Hi Allen,
> 
> Allen Bierbaum wrote:
> 
> > Is there any way to tell the program options parser to ignore
> > options that it does not recognize? If there is no option like this,
> > how can program_options be used with other option parsers?
> 
> Jody wrote:
> 
> > I am not familiar enough with the library to know the "correct"
> > method. The only thing I can think of is that the interface is
> > lacking.  I took a few minutes to look at the code in
> > libs/program_options/src/cmdline.cpp and it looks like the only
> > interpretation is empty or a valid option name.
> 
> Ok, let me start with a caveat: ignoring unknown options can be
> ambiguous:
> 
>    program --something 10 --known_option
> 
> Now, is "10" a value of unknown option or positional option? To remove
> the problems all unknown options must use this form:
> 
>    --something=10
> 
> which may be problem, or may not, depending on your situation. What do
> you think?

I think your example actually brings up several issues.

First, I was actually a bit surprised to see in the docs that the
library does not require positional parameters to follow all
non-positional parameters.  The normal unix use cases typically expect
options first, then positional parameters.  If the user wants to "end"
the options early, then a "--" is inserted as an option that
specifically says to end option processing and begin positional
processing.

The ambiguity in your example is actually caused by the interpretation
of positional options.

I guess if I were writing a custom parser to handle "--something 10"
then I would give the custom parser some state, and it would have to
know what to expect.

> 
> > So, at this stage, I think it requires an interface change to
> > support this option.
> 
> The detail::cmdline constructor actually has 'allow_unregisted'
> parameter, which is intended to help with this. However, no non-detail
> interface allows to specify. Frankly, I don't know if I forgot about
> this or just decided to wait for a user to request this feature
> explicitly.
> 
> Adding a new method to the 'common_command_line_parser' to set
> 'allow_unregistered' flag and then tweaking
> common_command_line_parser::run should do the trick? Opinions?

Maybe.  I am trying to think in terms of bigger picture use case
support.  I think we need the following...

1. Ability to tell the parser to be in "strict" mode or something like
that, where it assumes options come first, and "positional options"
follow.  This will remove all ambiguity in parsing options, and AFAIK,
it is consistent with just about all conventions.

2. Currently, a custom parser can pass two kinds of information; either
"I do not recognize this option" or "I recognize this option, and here
is a name/value pair that I want you to use as a substitute for the
option."  It needs to be enhanced so it can also pass "I recognize this
option, and you should ignore it."

3. Some way for the main cmdline parser to do all its parsing, and
return all "unrecognized" stuff, without an error.  This way, parsers
can be chained.  For example, parsing in such a manner...
        program --something 10 --known_option
would resognize --known_option and I can then as for "parsed" options
and get a vector of strings representing the parsed options.  I should
also be able to get a vector of strings of "unparsed" options.

I think this will allow me to chain option processing in almost any
manner...