Boost logo

Boost :

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.


> 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


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


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,

Boost list run by bdawes at, gregod at, cpdaniel at, john at