[boost] Re: Some comments on program_options/howto.html

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-11-02 10:56:59

Hi Peter,

> I dutifully followed the link from the --no-foo thread, and I have some
> comments.
> 
> The Winmain Command Line section says split_command_line in the text,
> split_winmain in the example code.

The text is wrong and example is right, the function is called
"split_winmain". I'll fix the typo right now.

> The Response Files section shows example code for parsing a response file
> using Tokenizer. Why shouldn't one be able to use split_command_line
> instead? There doesn't seem to be any difference between a command line in
> string format and a response file.

Good question. The problem is that split_winmain uses Windows-style quoting
rules, while tokenizer uses more Unix-like rules. I'm not sure which syntax
the response files should use.

> Also, response file support doesn't seem proper. Response files should
> work like this:
> 
> @file1 --option=value @file2
> 
> If file1 contains --option, it will be overriden by the command line.
> Similarly, all options in file2 will override both file1 and the command
> line --option=value. From a cursory look at the example, this doesn't seem
> to be the case, but I may be wrong. 

The behaviour of the example is that command line will override anything
specified in response files. If that behaviour is not correct for Windows,
I'd need to modify the example a bit -- by iterating over vector of options
which is returned by parse_command_line, and replacing @ options will those
from response file.

> An additional parser could have been 
> used to enable this behavior if it were possible to return more than one
> option/value pair from it. (This would also allow "option bundles" like
> -O1 expanding into a set of option/values.)

In fact, I plan to make additional parser return vector<option>. Of course,
this will be done only after release.

- Volodya