[boost] Re: Re: Program Options Custom Notifier Function Order of Execution

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-12-01 06:58:58

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