From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-05-22 00:08:34
Hi Hartmut,
Hartmut Kaiser wrote:
>> The formal review of Vladimir Prus' Command Line & Config
>> ("program_options") library starts today, May 21, and will
>> continue until Monday, June 2nd. I will be serving as review manager.
>
> I'll start with my conclusion: I think, that the program_options library
> of Valdimir Prus should be accepted into Boost.
Thanks!
[...]
> The supported argument format is customizable, this customization is
> restricted to the most used unix style idioms.
>
> I don't know, if it is possible to extend this to other styles too (as
> using other characters as the option starting character, for instance
> '+'), and if yes, how to achieve this.
I though about it, and believe it's possible. For example, you might
support
-wXXX
+wXXX
options, the first of which disables some warning, and the second enables
it. All is needed is to provide custom parser for "+w" syntax. This is
similiar to
-fsomething
-fno-something
syntax, and the "custom_syntax" examples shows an approach to handle it.
> 2. The library supports to analyze command line style options (based on
> argc, argv). I think it would be helpful to support the direct command
> line syntax too (based on the command line string), even if this might
> be system dependend.
We've discussed this on boost-users ml, and this feature --- strictly
speaking, parsing WinMain command line --- is planed to implementation.
> 3. The library supports to use configuration files as an alternative
> means of supplying the options, but it is restricted to a windows like
> INI format by now. It seems to be useful for me to support the same
> option formatting, as allowed for the command line. Ok, this
> implementation is very simple and straightforward - I had to do this for
> the Wave preprocessor driver - but this feature should be useful in
> other contexts too.
Agree. I even started implementing this feature, but there are some issues
which I'd like to discuss with potential users first. Specifically, if
response file has
-I foo
line, then my current code treats it as "-I" option with " foo" argument
(note the bogus whitespace). Guess parsing of string is needed, as you
propose above.
Thanks for your review,
Volodya