Re: [boost] Re: Preliminary submission: command line & config fil e library

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-01-17 01:58:44

Rozental, Gennadiy wrote:
>>>Does your parser supported all of them?
>>
>>Maybe not. However, the unsupported one probably differ on in prefix
>>("/" vs "-"). And something really custom ("-fno-unsigned-char") can
>>be handled via "additional_parser" mechanism (there's an 
>>example of it in
>>the documentation.
> 
> 
> Do you support names with space inside? Or with any special symbols you are
> using for definition? But it not my point. You always working under
> assumption of <name><value> format. In my case it's only one of the
> supported formats (most useful probably).
> Will you support this format for example:
> 
> my_program ( 0, 1) ( 1, 3) (( 0, 1), 15 ), (( 0,1), (7.8) ) >
> This is input  of 2 points circle and line. Here chain_lookup_policy could
> be useful.

What if I want C++ expression specified on the command line? Sure, I don't 
want make C++ parser operate on command line. Rather, I'd write

     my_program "f(1, 2) + 10"

I don't need "chain_lookup_policy" where a couple of quote characters will do.

>>I did not say that should be coupled. But you'd need 
>>something which keeps 
>>option description independent from parser. You design seems 
>>much more 
>>coupled: the code which parsers the options, 

[...]

I really can't comment further without seeing the code.

>>>>Oh.. it's even more complicated! Are your command line 
>>>>syntaxes that complicated?
>>>
>>>
>>>No. But this way I could parse out UDT from command line input.
>>
>>That's *very* complicates solution. Assume I'm parsing 
>>"FontName" class
>>
>>    --font=times-*-koi8
>>
>>All I need to parse this out, is to declare operator>> for 
>>FontName. The
>>problem with spaces is overcome by quoting.
> 
> 
> operator>> with what first argument? istream? string? That what my
> default_interpreter is using. But by design does not require you to use one.

It not required in my design neither. If your option value if C++ expression:
well, provide your own validation function for that parameter.

>>OK, that's possible, but quite uncommon. I'd pass the data via file.
> 
> 
> Does your config_file facility support defining program parameters in XML
> format?

No. Does yours? Getting really picky, does yours allows to validate XML 
against DTD?

>>But really, you got be quite confused by now. First you say 
>>that 90% of
>>users don't care about command line, and now you give really uncommon 
>>examples. I understand that you're trying to say that your 
>>framework allows
>>abribtrary customization, but I suspect 99% users will never 
>>need it, and
>>therefore it will be only additional section in documentation.
> 
> 
> Yes. It's only explain why I strive for flexibility. As for the regular
> case, as I mention before I also prefer more expressive solution.

OK, need to see the code to tell if flexibility gets in the way or not.

- Volodya