> 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"?
> 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?
> 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.
> 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.
> In 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( "=", "?"
)
> 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.
> Do you need this really?
Why not? If my parameter is in a form of question, why not have '?' at the
end?
> 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?
>
> It looks like cla::argument is provided by the framework.
It is. But it does not mean that all of them are "typed"
> You'd still need to function-like logic inside your code, I
> think. You should
> call object of some concrete type, and "any functor" must be
> converted to
> that type. Is that duplication reasonable?
I don't get this. May be it will become more clear from sources.
> > operator<<( config::parser, program_options )
> > ...
>
> And what those operator<< will do?
Feed option definitions to the cla::parser.
Gennadiy.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
