On 1 Dec 2004, at 11:58 am, Vladimir Prus wrote:
Hi Tony,
Hi Vladimir. Sorry for the late reply.
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. 2) default(10) should really be default_value(10). 3) There should be no ; at the end of the third line. 4) notify(&your_function) should really be notifier(&your_function) 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.
The order of invocation is independed of the order on the command line, it's just lexicographical order of the option names.
I don't like this. If what you claim is true then I'm losing control over the program.
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). 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.
Why do you need specific order?
There's no guarantee at all. The idea is most of the time you don't need specific order. If you describe your problem, I might offer more specific help.
I must admit that my original e-mail has taken this a little too extreme (all options are commands and none are "options"). Most of the time we don't need specific order which is true for most Unix commands and that's the way people are use to. However, I believe luck favours the prepared. The fundamental principle of writing a library (in my opinion) is to provide easy and friendly functionality that respond to users' need with all (well, most) possibilities.
There are two possibilities:
- Each option is a completely independent command. Then you don't need variables_map at all. You just have a map from option name to function that executes the command, and you'll iterate over returned options, calling those functions.
I admin this is an extreme case. Even with my original design, I would have some real options instead of commands in the mix.
- 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\> <Commands> a Add files to archive c Add archive comment cf Add files comment cw Write archive comment to file d Delete files from archive e Extract files to current directory f Freshen files in archive i[par]=<str> Find string in archives ... <Switches> - Stop switches scanning ad Append archive name to destination path ag[format] Generate archive name using the current date ap<path> Set path inside archive ... p[password] Set password ... vp Pause before each volume w<path> Assign work directory x<file> Exclude specified file x@ Read file names to exclude from stdin x@<list> Exclude files in specified list file y Assume Yes on all queries z<file> Read archive comment from file Some special syntax are used to separate the commands and the switches (options) which I think is a good idea. Mixing commands and options are not uncommon and the above form of allowing this feature seems a good starting point.
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. I'm looking forward to hear from you again. Tony
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Tony H. Bao T.H.Bao@Swansea.ac.uk