Re: [Boost-users] [program_options] patch - optional argument support (gnu getopt_long style)

From: Bryan Green (bgreen_at_[hidden])
Date: 2007-08-07 17:05:23

Vladimir Prus writes:
> 
> 5. For 
> +            // A value is optional if min_tokens == 0, but max_tokens > 0.
> +            // If a value is optional, it must appear in opt.value (because
> +            // it was 'adjacent'.  Otherwise, remove the expectation of a
> +            // non-adjacent value.
> +            if (min_tokens == 0 && max_tokens > 0 && opt.value.empty())
> +                --max_tokens;
> +
> 
> what will happen if in future, there's some option that accepts [0,10]
> tokens. Your code will make it access [0,9] tokens, IIUC. Maybe you should
> explicitly check for max_tokens == 1?

My intuition was that it is not possible to have an option that accepted
[0,10] arguments without raising ambiguities, unless it used an extension to
the implicit_argument format.  When checking how 'multi_token' worked, I
found that it in fact doesn't work (ticket #1132).

The extension I envision would use commas as delimiters, such as:

  --do-something=again,and_again,with_feeling_this_time

Under special circumstances, I can see a way to eliminate the ambiguity in
multitoken - you just need a unique marker indicating the end of the option:
either the leading '-' of the next option, or EOL, or some user-defined
delimiter that identified the beginning of positional parameters.

If such a future possibility is preferable over the suggested
implicit_argument method for multiple tokens, I'd be happy to change the
check to be (max_tokens == 1).

Regards,
Bryan