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

From: Rozental, Gennadiy (gennadiy.rozental_at_[hidden])
Date: 2003-01-16 13:00:03

> > 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.

> 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, 

part that identify arguments in key_policy, part that parse argument value
in parameter that uses some kind of interpreter.

> the code which keeps option description 

in cla::parameter

> and the code which keeps the resulting value is 

in cla::parser

> all in "lookup policy".

This one only responsible for search algorithm
Either <name><value>, either <first> <second> ...., and so forth.

> >>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.

> 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?

> 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.

> 
> - Volodya

Gennadiy.