Hi Tony,
the user-provided notifiers are called by the "program_options::notify" function.
I do have a call to notify (See below)
Ok, I just did not see it in your original code snippet.
in the example but do you mean notify (my_function1) ?
No, surely not.
boost::program_options::store(boost::program_options:: parse_command_line(argc, argv, menu), menu_map); boost::program_options::notify(menu_map);
This looks like.
I don't know if you tried to use this library but it seems the documentation regarding notify is wrong (Or I'm wrong). Try to compile the exact example given by the docs results in an error. replace notify by notifier will cause the function to be called. Maybe I'm missing something here.
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.
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.
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.
What I wanted is to have the user line up their request to the program as options on the command line and each time an option is read, something will happen as the order they were read. I would like to collect some option information as first like files in the example but it's not essential.
What you are saying is that these options are treated as arguments to functions but I want them to act more like commands to the program that will cause some action, so any option has a purpose and a place as when and where to be used instead of dumping all to the program as configurations.
This explains something. This also suggests you don't need name->value mapping that's provided by the variables_map class. I would suggest you use the 'parsed_options' class which is returned by the parse_command_line function: typedef basic_parsed_options< char > parsed_options; http://boost.org/doc/html/parse_command_line.html http://boost.org/doc/html/basic_parsed_options.html 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. - Some options are "commands". Some are ordinary options and affect the execution of commands. Then, code like this would work: parsed_options p = parse_command_line(......); parsed_options p2; p2.description = p.description; for(unsigned i = 0; i < p.options.size(); ++i) { if ( /* p.options[i] is command */ ) { // Store the options found so far to 'vm' variables_map vm; store(p2, vm); notify(vm); // Execute your command, supposedly making use of // options stored in 'vm'. } else { p2.options.push_back(p.options[i]); } } Let me know your opinions on the above approaches. This looks like a candidate for "howto" section of the docs. - Volodya