Rozental, Gennadiy wrote:
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 writeMaybe not. However, the unsupported one probably differ on in prefixDoes your parser supported all of them?
("/" 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.
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.
That's *very* complicates solution. Assume I'm parsing "FontName" classOh.. 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.
--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.
No. Does yours? Getting really picky, does yours allows to validate XML against DTD?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.
OK, need to see the code to tell if flexibility gets in the way or not. - Volodya _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
