Re: [Boost-users] program_options positional and required arguments

Subject: Re: [Boost-users] program_options positional and required arguments
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2009-11-09 05:45:02

Yang Zhang wrote:

> On Sun, Nov 8, 2009 at 11:56 PM, Vladimir Prus
> <vladimir_at_[hidden]> wrote:
>> Yang Zhang wrote:
>>
>>> I had to add the exe option to the regular (non-positional)
>>> options_description as a vector<wstring>, causing it to show up as an
>>> option in the usage message.
>>
>> You can create a hidden options group and put 'exe' there.
>>
>>> Omitting it resulted in errors about the
>>> option being unregistered (even after trying to add
>>> allow_unregistered). Why would I get this error?
>>
>> Because you say that all positional options should become values of the
>> 'exe' option -- that you did not define.
> 
> But I *do* define it, in the positional_options_description....

Well, that does not count as definition -- positional_options_description
is merely a thin map into real options.

> If you look at the code, notice that "exe" has to be defined twice, in
> two different description objects.

Yes, indeed, that's because the options_description is the *primary*
description, and describes types and other things. positional description
only relays to the primary description, and is generally unable to
specify anything about the option.

>>> Shouldn't the
>>> wcommand_line_parser::run method be doing this checking after it has
>>> collected all the sets of option descriptions? 

I don't understand this question.

>>> Can I get rid of this? 
>>> What's the proper way to express what I want?
> 
> I guess these questions still stand. And the only suggested change to
> do things "properly" is to make "exe" hidden? Besides, can't a user
> still perform --exe blah, even if it's hidden from the usage message?

Yes. Is it that much of a problem?

- Volodya