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

Yang Zhang wrote:

On Sun, Nov 8, 2009 at 11:56 PM, Vladimir Prus 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