[boost] Re: Program Options Custom Notifier Function Order of Execution (Further Discussion)

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-12-06 03:23:38

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