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

From: Rob Stewart (stewart_at_[hidden])
Date: 2004-11-30 17:10:44

From: Jody Hagins <jody-boost-011304_at_[hidden]>
> Vladimir Prus <ghost_at_[hidden]> wrote:
> > > 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?
> > 
> > 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.

Regularity is good.

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

Reasonable.

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

You could have the parser, custom or otherwise, call an
unrecognized_argument function that, by default, throws an
exception, but could be customized.  unrecognized_argument()
could collect such arguments and maintain state, as desired, to
act when it has enough information.

You could even call unrecognized_argument() with an object from
which it can extract arguments such that those arguments are no
longer visible to the parser.

Another approach is for the parser to use the decorator pattern
such that passing a custom parser doesn't preclude owning and
forwarding to a default parser.  Then, the custom parser can let
the default parser try its hand and, if the default parser fails
to recognize the argument, the customer parser can give it a go.
If both fail, then the framework can cry foul.

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

Providing a callback, like unrecognized_argument(), leaves to the
client whether the right behavior is to collect them in some
container.

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;