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...
action_t action = a_none;
if (option == "--something")
state_ = s_something;
action = a_consumed;
action = a_consumed;
char * p;
long val = strtol(option.c_str(), &p, 0);
if (/*something is valid*/)
state_ = s_idle;
// 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?
// return something saying that I did nothing with this option
// return a name/value tuple, similar to the current interface
// return something saying that this option has been
// consumed, and the driver should pretend like it
// never even existed.
> > 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk