> > 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.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
