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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2007-08-08 02:22:23

Bryan Green wrote:

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

Yea, it's broken now.

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

I'm presently thinking that multitoken option should stop on any token
that looks like an option. That includes "--" -- which can be used to
terminate the list of options and start positional options.

So yes, I think max_tokens == 1 will be right now for.

- Volodya

> 
> Regards,
> Bryan