Rozental, Gennadiy wrote:
I'd like to draw an analogy with shared_ptr. You can provide smart pointer with 5 policy parameters, that user can redefine. Still, I would use
boost::shared_ptr, just because I don't want 10 incompatible smart pointers in my program due to small advantage each one has in special situation.
What if changing to custom ownership policy will bring you 10% speedup in effciency important part of the code? Would you still say - "never, I only use one smart pointer in a program"?
I'm likely to eliminate shared pointers in that part altogether. Further, what if in 6 month the code is not longer performance bottleneck, but different smart pointer is still there?
Likewise, if you have a single interface for declaring options, you should
settle of a fixed set of properties. I believe that your "handler" and my
"validator" and "notify" mechanisms can be used to cover situation where that
set of properties is not sufficient.
I don't say that you solution is unable to do anything. But I still prefer more flexible one. For example what if my parameter has 2 descriptions, one long - for long help message and one short for usage message. Where does it fit in your interface?
That's a good question. Really. I'd derive a new class from option_description and add the required member functions. There are some problems now, which should be fixed before this recipe can we working --- some interfaces have to suffer minor change. But surely, no complete rewrite is needed.
This has some drawbacks:
If you don't have such single interface, you'll reduce chances for reuse.
If a module adds options to global parser using some non-standard features,
you'd have to carry that global parser together with the module.
I do not completely understand yuor "module" principles. So could not comment on this. But As I mention, in my terms one could define several parsers that does not need to know about each other and process cla in chain.
1. Each module has to be given "data sources". If that's argv,argc. It's probably OK. What if it's registry?
2. Each module has to depend on parsing library, including parsers.
Did you look at "option_description" interface. The constructors have at most three parameters. I positively can't envision any confusion.Add second description, optional/requires, mulitplicable (those are some of the "features" supported by my parameters) and you could easily see one.
Why should I add those as constructor arguments?! Here's an example from the docs:
desc3.add_options()
("output,o", "file", "where to send output")
("magic", "value", "magic value for the program")
.default_value("43")
;
You see, "default_value" is quite explicitly named.
As my example above shows, you can use simple syntax for two arguments and explicit/named for all others. Take a look at Boost.Graph: it uses named arguments, but mostly for numerous details such as "color_map". You don't have to writeIn Python, you can use named arguments to function. What you propose looks like using named arguments for calling function with two or three parameters.
Possibly much more in my case: cla::named_parameter<int>( foo ) << cla::optional << cla::default_value( 1 ) << cla::place_to( foo_value ) << cla::description( "my lovely foo argument" ) << cla::format_descr( "integer value" ) << cla::prefix( "/" ) << cla::separator( "=", "?" )
transitive_closure(graph_param(g));
I might be wrong, but using "?" to mean optional construct is almost universal
convention. I can hardly imagine it's non-obvious.
Maybe for unix users. You assumption is not obvose in general case.
Bikeshed. The question is up for others.
Do you need this really?Why not? If my parameter is in a form of question, why not have '?' at the end?
Uph.. I'm sorry, I completely misunderstood your question. If you want
my_program --roll_trace_file? "yes"
you can have it, without any efforts from my part:
options_description desc;
desc.add_options()
("roll_trace_file?", "arg?", "roll trace file)
;
"rool_trace_file?" names the option, or in your terms, parameter.
"arg?" specifies that there's an optional value, called "arg?". The
name of value will be used only in help message.
I think that *existing* habits shold be supported. However, the library should
encourage some "standard" command line style. Contrived command line style is
only an inconvenience to user. As an example: what does "-r" option to CVS does? (It has 2 unrelated meanings, and about 4 syntax variations)
May be that's because they stick to one-char parameters identification instead of more expressive solution?
I think that if you have "--revision" which can occur two times for one command, one time for another, and has special value syntax for the third, it's still confusing. The command line syntax is just too complicated.
operator<<( config::parser, program_options ) ...And what those operator<< will do?Feed option definitions to the cla::parser.
Eeh.. that's only possible if program_options, config::parser, and cla::parser have the same interface for declaring options. If you add custom modifier to cla::parser, you have to add it to program_options, and the to config::parser and then to registry::parser, if you have it. - Volodya _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
