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

From: Jody Hagins (jody-boost-011304_at_[hidden])
Date: 2004-11-24 10:27:37

On Wed, 24 Nov 2004 17:14:03 +0300
Vladimir Prus <ghost_at_[hidden]> wrote:

> Caleb Epstein wrote:
> 
> > On Wed, 24 Nov 2004 10:27:59 +0300, Vladimir Prus <ghost_at_[hidden]>
> > wrote:
> >> 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 it is unreasonable to expect all command lines to be
> > specified in this way.  If --something expects an argument, then 10
> > is that argument.  
> 
> Well, I obvious don't know if an unknown option expects an argument
> ;-)

Right, but the custom parser better.  It should hold state and know what
is supposed to come next.  However, it can only do this if the custom
parser is allowed to eat up the option, leaving the "driver" with
nothing to do at all for that option (like a Jedi mind trick, "This is
not the option you are looking for.")

Imagine a custom parser written like this...

enum action_t
{
  a_none,
  a_modified,
  a_comsumed
};

action_t action = a_none;
switch (state_)
{
  case s_idle:
    if (option == "--something")
    {
      state_ = s_something;
      action = a_consumed;
    }
  break;

  case s_something:
  {
    action = a_consumed;
    char * p;
    long val = strtol(option.c_str(), &p, 0);
    if (/*something is valid*/)
    {
      state_ = s_idle;
    }
    else
    {
      // I expected a value for "something"
      // What do I do here?  There is no way to return an error
      // to the driver caller.  Should I throw an exception?
    }
  }
  break;
  
  ...
}

switch (action)
{
  case a_none:
    // return something saying that I did nothing with this option
  break;

  case a_modified:
    // return a name/value tuple, similar to the current interface
  break;

  case a_consumed:
    // return something saying that this option has been
    // consumed, and the driver should pretend like it
    // never even existed.
  break;
}

> 
> > If --something is a flag then its either an unknown 
> > argument 
> > or (if you allow argument vector rearranging ala GNU getopt) 
> > it is the first positional parameter.
> 
> While it's possible to consider all unknown options to be positional
> options, this still leaves the question what to do with "10". Should
> it be passed to the application as position option?

If you want to allow positional options to be mixed with non-positional
options, then yes, it would be treated as a positional option.

> 
> > Allowing unknown options to be ignored is a very desirable feature,
> > though it should be disabled by default.
> 
> I just don't see any solution to make unknown options work without
> either-- requiring --something=10 format
> -- requiring that all positional options are at the end

If the custom parser can actually "consume" options, then the "10" would
not be left over at all...  I am afraid we have a misunderstanding
somewhere...