Re: [boost] [program_options] post-review version

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-03-24 04:19:25

Hi Hartmut,

> > Since the interface has changes quite a bit, the brief list
> > of changes is included in docs, to help with migration. See
> >
> >     http://zigzag.cs.msu.su:7813/program_options/html/ch01s04.html
> >
> > All comments are very appreciated.
>
> In addition to the mentioned interface changes I've stumbled over the
> following issues/incompatibilities with the reviewed version:
>
> 1. the parse_command_line() function taking a vector<> of the arguments
> doesn't exist anymore. Is it possible to re-add it? This seems to be as
> easy as adding:

The problem is that the number of overloads of 'parse_command_line' was too 
high. What about using

   vector<string> v;
   command_line_parser(v).options(desc).run()

? This syntax essentially emulated named function parameters and avoid the 
need to have large number of overloads.

> 2. The examples doesn't seem to be updated to the new po interface (at
> least the real.cpp and regex.cpp examples)

Yes, 'real.cpp' and 'regex.cpp' are out-of-date, that's why they are not built 
by Jamfile. I'll try to do something about it.

> 3. As I've already pointed out, it is very important (at least for me, but
> I assume for others using older versions of the library too) to have some
> means of getting the version of the po library. I suggest adding:
>
>     #define BOOST_PROGRAM_OPTIONS_VERSION 0x0200
>
> to the program_options.hpp file, or to a separate file, which is included
> by all the other po headers.

This is possible, but let's discuss how to deal with interface changes, see 
below.

> 4. Now, that the options_and_arguments class has gone, is there a means of
> getting access to the arguments given on a command line (I mean all the
> remaining stuff, which isn't recognized as a valid option/parameter)? I
> can't find any documentation on this topic and wasn't able to find anything
> related browing through the sources.

Yes.
1. Use 'positional_options_descriptions' to handle positional options too.
2. The 'parsed_options' class returned by the parser has a vector of 'option' 
instance. An option which has 'position_key' not equal to -1 is positional 
option. So can run remove_copy_if to get positional options

> 5. In the file overview.xml in the code box under the Storage component
> heading the argument sequence for the store() function doesn't match the
> corresponding documentation/code.

Fixed, thanks!

> 6. I find it very hmmm distracting, that the syntax of the add_options()
> construct has changed significantly! Isn't there any way to make it more
> compatible with the syntax used in the reviewed version? 

I'm afraid it's hard. The major reason for change is that the revieved syntax 
was somewhat string-oriented. For example, default values were specified as 
strings, and in general, the information about real type was so deeply 
hidden, than only the 'parameter' function knew the type.

> The only way I see
> now is to include two versions of the add_options() code into my
> application (Wave), which is very ugly! Or, I have to abandon the support
> for the 'older' syntax, but this puts additional burden onto the users of
> Wave, because they will have to keep track of the version of the po library
> to use. I would very much like to keep Wave compatible with the
> pre-released version of the po library too!
> Certainly, this issue seems to be important until the next Boost release
> only, but this may take some time and even then I would like to support the
> usage of Boost at least beginning with the V1.30.2.

That's a question. I meant that it would work like this:
1. I retain the prereview version on my site and on sf.net.
2. When you have the time you upgrade the syntax to the new one and notify me
3. I remove the old version. At this moment, users would have to obtains the 
new version of program_options. It's possible to use 
BOOST_PROGRAM_OPTIONS_VERSION and #error to produce nice message "Please get 
new program_options library" rather then a number of compilation failures.

This means some work for users, but it's one-time. On the contrary, supporting 
two syntaxes at the same time might be really hard.

> 7. What's the equivalent for the parameter and validator classes, which
> were contained in the reviewed version?

By validator, you mean the way you handle 'include_paths' class in Wave?
The syntax you've used is gone, but you can achieve the same effect with 
specialization of the 'validator' class:

  template<>
  void validator<include_paths>::operator(.....) { ... }

The argument and the body should be the same as for include_path::validate. Or 
you could just forward to that member function.

As for 'parameter' -- it was function in the revieved version. It's now called 
'value' and does not take the "name" argument.

- Volodya