Hi Tony,
Can you point me a a specific example which does not compile. While most code in the docs is derived from code in the "example" directory, it's possible that some typo was made.
On page
http://www.boost.org/doc/html/program_options/overview.html
under semantic information, the following piece of code.
options_description desc; desc.add_options() ("compression", "compression level", value<int>()->default(10)); ("email", "email", value< vector<string> >() ->composing()->notify(&your_function);
1) Order of arguments of add_options() are wrong. value<int>()->default(10) is the second argument and "compression level" should be the third argument. And the same order for email option. 3) There should be no ; at the end of the third line.
This is already fixed in CVS.
2) default(10) should really be default_value(10). 4) notify(&your_function) should really be notifier(&your_function)
You're right on those points, which are now corrected. Quite a number of typos for a single example ;-)
5) I believe it's a good idea to use full namespace in examples. It helps to know where the functions and classes come from.
Not sure, as everything's from boost::program_options.
It depends on your point of view. In my opinion deterministic order of 'notifier' calls is a feature, and each feature must have a real use case to enter a library. Imagine loading options from LDAP server (I hope to implement that one day). Does it make sense to talk about order of the options? Even for config files, the order of options is generally not important.
Once again, I apologise for the overly strong words used in my first reply (It was a long day).
No problem.
As for the need of such feature:
"I am co-developing a Generic SAT library that devotes to General Satisfiability problems in computer science and logic. I would like to provide the user the options to specify their parameters as a sequence of instructions to some application, a SAT solver developed using my library for instance. The instructions could be first generate some random formula with these parameters, try some algorithms on them to solve them for an hour with this amount of memory, stop current job, generate more formula, try different algorithms etc..."
And thank you for agreeing with me that this IS a use case.
For the list readers: the above is quotation from email that Tony sent me offlist. I agree this is a valid use case.
- Some options are "commands". Some are ordinary options and affect the execution of commands.
And this, I believe, is a feature that deserves consideration. The following lines are copied (shortened) from the help menu of utility rar.
RAR 3.41 Copyright (c) 1993-2004 Alexander Roshal 2 Nov 2004 Shareware version Type RAR -? for help
Usage: rar <command> -<switch 1> -<switch N> <archive> <files...> <@listfiles...> <path_to_extract\>
...
Some special syntax are used to separate the commands and the switches (options) which I think is a good idea.
boost::program_options uses "--" for that purpose.
Then, code like this would work:
... your code
Let me know your opinions on the above approaches. This looks like a candidate for "howto" section of the docs.
I had a look and tried it. Thanks. And yes, I hope you add it to the "howto" section.
Great. I'll add it soon. BTW, I have another idea. If you have "options" and "command" and the order of "options" is not important, then you can make command into positional options, something like: prog --mmx do_this do_that When parsing 'do_this' and 'do_that' like positional options, they will be stored in the same order they were specified. Of course, if you need to interleave options and commands and command should be influenced only by preceeding options, the code that I've given is the only way. I'll document this and think if some simplification is possible. - Volodya