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