program_options: one-of-set option format
The boost::program_options library appears to lack the capability for one-of-set options, i.e. one of -a, -b, or -c, but not more than one, returned as an enumeration value in a common result for all the options. Currently I have a function: template<typename T> options_description& oneOf(options_description& od, std::vectorstd::string& names, T& t); which adds options for all the names to "od", with notifiers that update "t" with the "T" enumeration value corresponding to the particular option that the parser finds present using the ordinal position in "names" as a value. However, this is somewhat unsatisfying because detected errors (missing or too many choices) don't feed into the program_options reporting system. It also does not fit with the rather nice syntax used by the program_options library for option declarations. I also looked at using an external parser as supported by program_options, but this seems low-level overkill - you get a raw string to parse, but none of the nice facilities for abbreviation, long or short forms, etc. are usable. Lastly, I considered adding the capability as a native feature of program_options, but while the library is reasonably clean it doesn't seem to be designed to support any inter-option linkages as required for reporting the result and verifying that only one of the set was present. So the question for this list: am I reinventing the wheel here and this oneOf capability already exists somewhere? If not, is there a better approach than my present purely extra-library solution? Thank you Ivan
Ivan Godard wrote:
The boost::program_options library appears to lack the capability for one-of-set options, i.e. one of -a, -b, or -c, but not more than one, returned as an enumeration value in a common result for all the options.
Currently I have a function: template<typename T> options_description& oneOf(options_description& od, std::vectorstd::string& names, T& t); which adds options for all the names to "od", with notifiers that update "t" with the "T" enumeration value corresponding to the particular option that the parser finds present using the ordinal position in "names" as a value. However, this is somewhat unsatisfying because detected errors (missing or too many choices) don't feed into the program_options reporting system. It also does not fit with the rather nice syntax used by the program_options library for option declarations.
I also looked at using an external parser as supported by program_options, but this seems low-level overkill - you get a raw string to parse, but none of the nice facilities for abbreviation, long or short forms, etc. are usable.
Lastly, I considered adding the capability as a native feature of program_options, but while the library is reasonably clean it doesn't seem to be designed to support any inter-option linkages as required for reporting the result and verifying that only one of the set was present.
So the question for this list: am I reinventing the wheel here and this oneOf capability already exists somewhere? If not, is there a better approach than my present purely extra-library solution?
I think the ideal approach would be to introduce new kind of value_semantics, say, enumerated_typed_value, so the definition might be: desc.add_options() ("whatever", enum_value("a", a)("b", b), "whatever desc) ; The xparse method of enumerated_typed_value would check that no value is set yet. The problems here are that: - xparse presently accepts only the values specified for the option, so it has no way to tell -a from -b - the command line parser assumes that one element of options_description results in one short option and one long option to be recognized, not several options, so some refactoring will be necessary I think the best way would be to introduce 'alias' mechanism, where -a would map to --whatever=a, and make enumerated_typed_value make use of this mechanism. I don't have any immediate plans to do that myself. HTH, Volodya
On Oct 12, 2008, at 3:15 AM, Vladimir Prus wrote:
Ivan Godard wrote:
The boost::program_options library appears to lack the capability for one-of-set options, i.e. one of -a, -b, or -c, but not more than one, returned as an enumeration value in a common result for all the options.
Currently I have a function: template<typename T> options_description& oneOf(options_description& od, std::vectorstd::string& names, T& t); which adds options for all the names to "od", with notifiers that update "t" with the "T" enumeration value corresponding to the particular option that the parser finds present using the ordinal position in "names" as a value. However, this is somewhat unsatisfying because detected errors (missing or too many choices) don't feed into the program_options reporting system. It also does not fit with the rather nice syntax used by the program_options library for option declarations.
I also looked at using an external parser as supported by program_options, but this seems low-level overkill - you get a raw string to parse, but none of the nice facilities for abbreviation, long or short forms, etc. are usable.
Lastly, I considered adding the capability as a native feature of program_options, but while the library is reasonably clean it doesn't seem to be designed to support any inter-option linkages as required for reporting the result and verifying that only one of the set was present.
So the question for this list: am I reinventing the wheel here and this oneOf capability already exists somewhere? If not, is there a better approach than my present purely extra-library solution?
I think the ideal approach would be to introduce new kind of value_semantics, say, enumerated_typed_value, so the definition might be:
desc.add_options() ("whatever", enum_value("a", a)("b", b), "whatever desc) ;
The xparse method of enumerated_typed_value would check that no value is set yet. The problems here are that:
- xparse presently accepts only the values specified for the option, so it has no way to tell -a from -b - the command line parser assumes that one element of options_description results in one short option and one long option to be recognized, not several options, so some refactoring will be necessary
I think the best way would be to introduce 'alias' mechanism, where -a would map to --whatever=a, and make enumerated_typed_value make use of this mechanism. I don't have any immediate plans to do that myself.
Does Program_Options support subcommands, like the traditional CVS and SVN command-line clients do? Subcommand support requires some sort of mutual exclusiveness, so code could be reused for the poster's problem. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
participants (3)
-
Daryle Walker -
Ivan Godard -
Vladimir Prus